Conversation design · Explore this field ↗ · Design · 2 min read
Clarify without interrogating
Ask the smallest question that safely separates the plausible paths.
Ambiguity is normal
People omit context because other humans infer it. ‘It won’t let me in’ may refer to a password, multifactor challenge, expired subscription, or service outage. A useful bot does not force the user to translate the problem into internal taxonomy. It presents the most likely distinction in plain language and keeps an ‘something else’ route open.
Use contrastive questions
Ask questions whose answers change the next action: ‘Do you see an error message, or does the page keep loading?’ is stronger than ‘Can you provide more detail?’ Reflect known context before asking again. If the system already has the order date, do not request it because a generic script says so. Explain purpose before requesting account, health, or financial information.
Know when to stop clarifying
After one or two failed repair attempts, the expected value of another question often drops. Offer a human, a ticket, or a safe alternative. Preserve the transcript and a concise machine-generated summary, but label the summary as a draft for the human operator. The user should not have to prove failure repeatedly.
Operator note
Build an ambiguity set from real conversations. For each common vague utterance, list the minimum differentiating question, accessible choices, prohibited data, and escalation point. Track repeated-question rate and loops, not only intent accuracy.
Build a repair ladder
For each ambiguous task, write three rungs. First, reflect the likely interpretation and offer the most useful distinction. Second, present a small set of choices grounded in what the service can actually do. Third, stop asking and offer another route. Add a separate rung for missing authorization and one for unavailable tools. This prevents an LLM from improvising endless variations of ‘tell me more.’ Review the ladder with support staff, because they know which details genuinely change resolution and which questions merely satisfy an old script.
Primary reading
Sources and limits
These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.