How to design a voice workflow around your business

Start with an outcome, not a list of questions

A workflow defines what should be completed during a call and what proves completion. “We spoke to the customer” and “the authorized system accepted the request” are different outcomes. Choose a concrete final state first.

Then separate required from optional data. Information supplied early should be retained instead of prompting the caller to repeat it. But an assumption must not become a confirmed field when a mistake would cause a consequential action.

• Implementation around your process

Design the normal path and exceptions together

Every step needs an entry condition, required data and an outcome. Branches define what happens after a short answer, correction, refusal or another question. Conversation order may be flexible; safety conditions for an action remain mandatory.

For each action, identify the trusted source, approval rule and recovery path. If a system is unavailable, the caller should understand whether the request is pending, failed or awaiting a person.

• Use information already provided, but do not let stale answers overwrite newer values.
• Recheck dependent fields when a decision changes.
• Before a consequential write, summarize exactly what the caller is confirming.

Worked dialogue: “სამზე” → “არა, ოთხზე”

In this illustrative conversation the service and date are already known. The caller says “სამზე” (“at three”). Do not ask for the date again. Clarify 15:00 versus 03:00 only when the context, business hours and earlier dialogue genuinely leave that ambiguity unresolved.

“არა, ოთხზე” (“No, at four”) changes only the time. Retain the name, service and location, then check availability for the new time. This Tbilisi-business example uses Asia/Tbilisi; another business may use a different agreed time zone.

An explicit example value is “18 September 2026, 16:00, Tbilisi time.” It is a teaching example, not an available slot being offered. Before persistence, restate the service, location, date and time, obtain confirmation and then request the authorized write.

Complete the requirements worksheet

Use non-sensitive example requirements below. Entries remain on this page: they are not submitted or saved to a server. Print through your browser and retain your notes before closing the page.

A goal, branch and acceptance test should be understandable together. If the requirement says “a retry must not create a duplicate,” the test needs to inspect the resulting records, not merely the spoken response.

From design to repeatable tests

Write dialogue after defining data and action rules. The prompt then explains an agreed process instead of inventing missing business policy.

1. 1

   Outcome and paths

   Define the goal, normal sequence and each failure exit.

2. 2

   Data and permissions

   Identify the trusted source, allowed tool, identity checks and approval requirements.

3. 3

   Dialogue and Georgian variations

   Write concise questions, early answers, varied time expressions and corrections.

4. 4

   Test and pilot

   Compare the dialogue with actual outcomes, run a bounded pilot and assess failures.

5. 5

   Iterate

   Add a test for every changed rule and rerun earlier scenarios.

Define acceptance before launch

Success is the agreed outcome and a truthful answer, not simply grammatical conversation. Each test needs starting data, caller utterances and an expected record state or reason for refusal.

• Several fields in one sentence: ask only for missing information.
• A last-minute correction: use the new value and renew confirmation when needed.
• A backend timeout: recover status without a duplicate.
• Access denied: respond safely without exposing information.
• Nobody answers the transfer: offer only the agreed, truthful next step.

• Quality-testing methodology
• Readiness checklist
• Integration assessment