A user asks for a claim status. The assistant asks for details it may already know, then asks more questions before offering any value. The sequence might eventually work, but it makes the user do unnecessary work. A conversational flow is the planned path through user turns, assistant prompts, decisions, and responses that gets someone to an answer or completed task. A good flow reaches that goal with as little avoidable effort as possible. section 1.1.1 section 8.2.1
Ask only when an answer is missing
Suppose store hours differ by location. If someone asks “hours of operation?”, the assistant asks which store they mean, then gives that store’s hours. If they ask for a particular store’s hours, it can answer immediately. Both requests reach the same goal; only one needs a clarifying turn. section 2.1.3
Listing 2.2 Sample conversations for store hours, dependent on location
User: hours of operation? #1 Bot: To view our store hours, please select a location. Bot: (Columbus, Dublin, Westerville, Grandview) User: Columbus Bot: Our Columbus store is open Monday through Friday, 8am - 8pm. User: hours of operation? Bot: To view our store hours, please select a location. Bot: (Columbus, Dublin, Westerville, Grandview) User: Dublin Bot: Our Dublin store is open Monday through Friday, 9am - 9pm. User: hours of operation for Grandview? #2 Bot: Our Grandview store is open Monday through Friday, 9am - 9pm.
Compare the sample conversations: the location question appears when needed and disappears when the user has already supplied the location. section 2.1.3
Design the path backward from the user’s goal. Identify what information an answer or API action actually requires, what the user has already supplied, and what context is available. Then ask for missing information in an order that feels natural. The channel matters: a security question that works on the web may be difficult by phone or insecure by SMS. Some answers, such as general store hours, may need no personal information at all. section 1.1.3 section 2.1.3
Watch for turns that make a workable flow harder than it needs to be:
- Questions the user cannot readily answer, ambiguous prompts, rigid input formats, too many choices, or details requested in a disjointed order. section 8.2.1
- Prompts or responses poorly suited to the channel, such as asking for an email address by voice or reading out a long URL. section 8.2.1 section 9.2.2
- An ending that is technically correct but leaves the original need unresolved. Offer an appropriate next step rather than making opting out the only practical choice. section 11.3.5
A flow also needs paths for unexpected replies and requests for help. If the assistant asks whether an appointment is for vaccines or testing, a user may answer “yes.” Repeating the same question can lead to abandonment or escalation; the reply and prompt need reconsideration. For an opt-out request, the assistant can clarify the user’s goal, offer self-service when it fits, or route an out-of-scope request to an appropriate agent. section 3.4.1 section 11.4.2
Improve flows with evidence from real conversations. Compare outcomes with the last step taken, inspect failures and opt-outs, and check whether a particular question repeatedly stalls users. Sample dialogues and flow diagrams make branches easier to review before implementation. An LLM can propose or simplify a flow, but its sample conversation is not a guarantee of how users will respond; review its choices, especially where mistakes or API actions carry risk. section 3.4.1 section 10.1.1 section 10.4
