Conversation design · Explore this field ↗ · Design · 2 min read
Write responses for action
A good bot answer is not an essay; it is a clear decision surface.
Lead with the state change
If an action succeeded, say what changed and when it takes effect. If it failed, say what did not change. If the system is advising rather than acting, use language that makes that boundary obvious. Avoid ‘all set’ when only a request was submitted. Users remember the confident phrase more than the fine print.
Layer detail
A strong support response often has four layers: direct answer, necessary condition, next action, and optional detail. Links should name the destination. Dates, prices, and policy quotations need a source and freshness signal. When the answer comes from retrieved material, citations help the user and the operator inspect the basis; they do not prove the model applied it correctly.
Expose uncertainty usefully
Do not translate uncertainty into vague hedging. State what is missing: ‘I can see the payment, but not the bank settlement status.’ Then offer the safest path. When several policies might apply, identify the deciding fact. If confidence is too low for a consequential answer, route rather than improvise.
Failure mode
Persona guidelines frequently overpower service clarity. Warmth is useful, but apology loops, exclamation points, and humanlike self-reference create noise. Put voice after accuracy, accessibility, and action semantics in the review order.
Edit against a response contract
Review important responses in a fixed order: outcome, scope, evidence, uncertainty, next action, and tone. Highlight every verb that could imply a completed change—cancelled, refunded, booked, submitted—and require a system-of-record result behind it. Replace generic links with destination names. Move conditions next to the claim they limit. Finally, read the answer at mobile width and aloud. This editorial pass is more reliable than asking the model to be concise, because it defines what concise must still preserve.
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.