Conversation Flow

A conversation flow maps a dialogue between a user and a system — bot, voice assistant, or AI agent — as turns: user intent → system response → clarifying questions → branches → confirmation → fulfillment. Unlike a screen flow, the "screens" are utterances, and the user can say anything at any point, so the flow must plan for the unexpected as a first-class path, not an edge case. Near-synonyms: dialog flow, conversation design spec, bot script, dialog tree. For voice-specific mechanics (wake words, earcons, no visual channel) see Voice Interaction Flow; for the evidence base on prompts, confirmation, and error copy see Voice & Conversational Interfaces and Designing AI-Powered Interfaces.

When to use

Designing a chatbot, support bot, voice skill, or LLM assistant that must complete tasks (not just answer one-shot questions).
Any flow where the system must collect several pieces of information before it can act (booking, ordering, configuring, troubleshooting).
Reviewing an existing bot that users abandon or that escalates too often/too rarely.

What it answers

What intents do we handle, and what happens for everything else?
What information must the system collect before it can fulfill each intent, and in what order does it ask?
Where does the dialogue branch, confirm, fail, and recover?
When and how does the conversation escalate to a human?

What it includes

Intents — the user goals the system recognizes (entry points).
Slots — the parameters each intent needs before fulfillment.
System turns — prompts, answers, confirmations (write real copy; a conversation flow with placeholder text hides the design).
Branches — user choices, ambiguous answers, corrections ("no, I meant…"), topic changes mid-task.
Confirmation points — implicit for low stakes, explicit before consequential actions (see Voice & Conversational Interfaces's confirmation-by-stakes rule).
Fallbacks — the no-match/no-input path at every turn, with a reprompt-escalation ladder (below).
Escalation to human — trigger conditions, and context handoff so the user never repeats themselves (Designing AI-Powered Interfaces).
End states — fulfilled, abandoned, escalated, deferred.

Slot-filling: the underlying pattern

Most task conversations are slot-filling machines: the intent defines required parameters, and the flow's job is collecting them across turns.

Intent recognized → any slots already filled from the utterance?
  → Yes: skip those questions (don't re-ask what the user said)
  → For each empty required slot: ask → validate → branch on answer
All slots filled → confirm (summary readback) → fulfill → wrap up

Rules that separate good slot-filling from interrogation: accept slots in any order and several per utterance ("commercial site in Detroit next Tuesday" fills three); one question per turn; validate as you go, not at the end; let users correct a slot without restarting; persist filled slots across interruptions and topic changes.

Error recovery: the reprompt-escalation ladder

At every turn, plan the failure path (Voice & Conversational Interfaces documents the ladder): first no-match → brief reprompt with a hint; second → more guidance and concrete examples or narrowed options; third → change strategy: offer an alternative channel, a menu of things that do work, or a human. Never repeat the identical prompt verbatim; never blame the user. Escalation to a human is a designed state, not an apology — transfer the transcript and filled slots with it.

The LLM era: guardrails and states, not rigid trees

With LLM-backed agents, the flowchart-of-every-utterance is dead — users phrase anything, interrupt, and jump topics, and the model handles the phrasing. What survives is the state and policy layer: which intents are in scope, which slots are required before acting, which actions demand explicit confirmation, when to escalate, what is refused. Design the conversation flow as guardrails and states the model must respect (plus test transcripts to enforce them), not as a script it must recite. See Designing AI-Powered Interfaces for human-in-the-loop, uncertainty, and agent-progress patterns; Specialized Flows § AI Agent Flow for the action-taking variant.

Common mistakes

Designing only the happy script; the first ambiguous answer derails it.
Re-asking for information the user already gave.
Stacked questions in one turn ("What service, and when, and where?").
Explicit confirmation on everything (kills pacing) or nothing (consequential actions fire on a misheard word).
Hiding the human exit to deflect tickets — a dark pattern that destroys trust in the bot (Designing AI-Powered Interfaces).
No end state: the bot fulfills, then dangles ("Anything else?" loops).

Worked example: booking drone mapping services

User:   "I need drone mapping services."
System: "Sure. Is this for a residential property, a commercial
         property, or a construction site?"          [slot: site type]
User:   "A construction site."
System: "Got it. For construction we offer progress photos,
         orthomosaic maps, or 3D models. Which do you need?
         You can pick more than one."               [slot: deliverables]
User:   "Orthomosaics and 3D models."
System: "Orthomosaic maps and 3D models for a construction site.
         What's the site address?"                  [slot: location]
User:   "4400 Woodward Ave, Detroit."
System: "To confirm: orthomosaics and 3D models at 4400 Woodward
         Ave, Detroit. Should I book the site survey?"   [explicit
                                                      confirmation]
User:   "Yes."
System: "Booked. You'll get a confirmation email with the pilot's
         ETA."                                       [fulfillment]

Branch — ambiguous: "It's for my company's building" → clarify:
  "Is that an existing commercial property, or a construction site?"
Branch — no-match ×3 on deliverables → "I can also connect you with
  our team — want me to have someone call you?"      [escalation]

Checklist

Every intent lists its required slots and their validation rules
Slots accepted in any order and combination; never re-asked
One question per system turn; real copy written, read aloud
Confirmation strategy set per action by stakes (implicit/explicit)
Reprompt ladder at every turn (hint → examples → change strategy)
Corrections ("no, I meant…") and topic changes handled mid-task
Escalation-to-human triggers defined; context transfers with it
Out-of-scope requests get an honest "can't do that, but…" path
LLM builds: guardrail states + test transcripts, not a rigid tree
End states defined: fulfilled, abandoned, escalated, deferred

Sources

Grice, H. P. (1975). "Logic and Conversation." In Syntax and Semantics 3. Academic Press — the cooperative principle behind conversation design.
Google — Conversation Design guidelines (developers.google.com/assistant/conversation-design) — archival since the Conversational Actions sunset, but the flow guidance stands.
Amazon — Alexa Design Guide (developer.amazon.com/alexa) — slot collection, confirmation, and multimodal dialog patterns.
Pearl, C. (2016). Designing Voice User Interfaces. O'Reilly.
Cohen, M., Giangola, J. & Balogh, J. (2004). Voice User Interface Design. Addison-Wesley — confirmation strategies, error recovery.
Nielsen Norman Group — intelligent-assistant and AI-chat usability research (nngroup.com).