Chatbot conversation design: clarify, fall back and hand off safely

Chatbot conversation design specifies what a bot says when it can answer, needs clarification, lacks evidence or must defer to a person. Start with the user’s task, write those routes in plain language and define what each route actually completes. A handoff message should distinguish a prepared summary from a transfer that someone has acknowledged.

By Ai Flowi · Published 10 October 2026

This guide supplies a copyable conversation tree and four transcripts for an enquiry desk. For the underlying dialogue concepts, read conversational AI; for retrieving approved answers, use the knowledge-base chatbot guide.

1. Define one task and its evidence boundary

Choose a bounded enquiry, such as identifying a workshop venue or checking what to bring. Write down which information the bot may repeat and which decisions belong to a person. An answer about a venue does not authorise a booking change. Establish a manual review destination before offering any transfer language.

Synthetic teaching packet: the fictional Birch workshop has a source card, CARD-B, revision A. Its entire approved text is: Workshop Birch meets in Room Cedar. Bring a notebook. Booking changes require coordinator review. Arrival time and coordinator availability are absent. These invented facts support the examples only; they describe no Ai Flowi service or actual event.

Keep the card identifier beside each answer so a reviewer can compare the wording. If the source changes or cannot be inspected, stop presenting its contents as current. A missing fact is an evidence gap; an unreadable source is an access failure. Both need an honest reply, but the review packet should preserve the difference.

2. Copy the enquiry conversation tree

The tree is an editorial contract, not executable routing code. Fill the source and review destination before adapting its messages. “End” means this dialogue attempt ends; it does not imply the underlying request was resolved.

ENTRY
State the permitted task and ask for the enquiry.
After each enquiry or clarification reply, go to
CHECK REQUEST AND AUTHORITY.

CHECK REQUEST AND AUTHORITY
If the user wants to stop: END without preparing a packet.
If the user requests a person or an action outside scope:
  Go directly to HANDOFF DRAFT, even if an answer is available.
Otherwise: go to CHECK SUBJECT.

CHECK SUBJECT
If the subject is clear: go to CHECK EVIDENCE.
If unclear after the one clarification: go to UNKNOWN.
Otherwise CLARIFY: ask one question needed to choose the answer.
On reply: return to CHECK REQUEST AND AUTHORITY.

CHECK EVIDENCE
If an applicable approved passage answers the enquiry:
  ANSWERED: give that answer and its source reference; end.
Otherwise: go to UNKNOWN.

UNKNOWN
Name the missing, inaccessible or conflicting evidence.
Go to HANDOFF DRAFT to offer a review summary.

HANDOFF DRAFT
Offer a summary; if declined, END without a packet.
If accepted, include the enquiry, known subject, source status
and open decision.
Leave an unknown subject unknown; do not require clarification.
Let the user correct or approve the summary.
Mark it PREPARED: no transfer has occurred.
Only after summary approval and transfer permission may an
authorised person move it to the agreed review destination.
Record acknowledgement separately; then END this attempt.

For this exercise, use one clarification attempt before offering review. That is a chosen design limit, not a measured optimum. Allow the user to correct the subject, request a person or stop at any point. Do not force them through an unrelated menu to reach those choices.

3. Review the four response states as text transcripts

The following are authored synthetic transcripts, not recorded bot outputs. Speaker labels and full sentences preserve the meaning without relying on bubble colours, icons or a diagram.

Answered: repeat only the supported fact

User: Where is Workshop Birch?
Bot: Workshop Birch meets in Room Cedar. Source: CARD-B,
revision A, venue sentence.

The venue is supported; directions, arrival time and building access are not supplied. Adding helpful-sounding instructions would enlarge the answer beyond its evidence. Keep the answer short enough that its source relationship remains obvious.

Ambiguous: ask for the missing subject

User: What should I bring?
Bot: Which workshop are you asking about?
User: Birch.
Bot: Bring a notebook to Workshop Birch. Source: CARD-B,
revision A, materials sentence.

The clarification asks for a workshop name because that selects the source. It does not request a phone number, account credentials or a full personal history. If the subject was already clear, asking again would add work without resolving uncertainty.

Unknown: say exactly what is unavailable

User: What time should I arrive for Workshop Birch?
Bot: CARD-B does not give an arrival time for Workshop Birch.
I can prepare that unanswered question for manual review.
Would you like a summary?

This chatbot fallback message names the missing detail and gives a concrete next choice. Avoid “Try again” when a rephrased question cannot create the absent fact. Preserve the question as unresolved even if the user accepts the summary.

Human handoff: disclose the current step

User: Please change my Birch booking. I want a person.
Bot: Booking changes require coordinator review under CARD-B.
I can draft your request for you to check. Nothing has been
sent, and coordinator availability has not been confirmed.
User: Yes, prepare it.
Bot: Draft: “Request for coordinator review: change a Birch
booking. The requested change still needs clarification.”
Please correct this summary before manual transfer.

A request to speak to a person should reach this route directly. Preparing the draft needs no booking identifier yet. If a confirmed review process later requires identity verification, collect it through that process, with an explanation of why it is needed.

4. Make the manual handoff packet explicit

Copy this packet alongside the tree. Keep factual observations separate from the decision the reviewer must make. The example is deliberately incomplete: the user has agreed to drafting, but has not approved a final summary or its transfer.

Packet reference: PRACTICE-B
Subject: Workshop Birch
User request: booking change; human review requested
Source inspected: CARD-B, revision A, change sentence
Supported boundary: coordinator review required
Missing detail: the specific requested change
Drafting choice: user accepted
Summary correction/approval: pending
Transfer permission and destination: not confirmed
Transfer status: prepared only; not sent
Recipient acknowledgement: none recorded
Personal details included: none

For operational takeover controls, consult the chat channel fields and workflow handoff reference.

5. Store a review draft with Create Document

Capability status: documented. For saving this conversation design, Create Document is documented in the catalogue; not production-tested by Ai Flowi for this configuration.

Use the Google connection setup for your own authorised account and the Google Docs integration reference for Create Document fields; provider usage is paid separately, and this supplied-text draft needs no model-provider API key.

example configuration, not a recorded test

Map title to “Birch enquiry design — review draft” and initial_text to the tree, four labelled transcripts and PRACTICE-B packet, in that order. Use the account selected for this review in google_account. Its exported options value is [], so the catalogue supplies no account name to copy.

The expected artifact is the supplied conversation design, with document returning JSON. In the saved text, check that the human-request branch still precedes clarification and that the packet retains both “Summary correction/approval: pending” and “Transfer status: prepared only; not sent”. A reviewer should be able to trace a booking-change request from the transcript to its unresolved decision without mistaking the document for a delivery receipt.

6. How do I check failures before using a chatbot conversation design?

Ask for the venue: the response must preserve Room Cedar and its source, without inventing arrival instructions.
Omit the workshop name: the first clarification must ask for that missing subject, rather than unrelated personal information.
Ask for arrival time: the fallback must identify the absent time instead of substituting the venue.
Request a person immediately: the tree must permit a draft without requiring an answer attempt first.
Ask “Where is Workshop Birch? I want a person.” The venue is answerable, but the first destination must be HANDOFF DRAFT. Record the venue question in the summary without ending on the bot’s venue answer.
After “Which workshop?”, reply “I want a person instead.” Return to the request check and offer drafting; do not ask for the workshop again as a prerequisite.
Decline or correct the summary: the packet must not record approval or transfer until the corresponding choice occurs.

Read every route aloud and review it using keyboard navigation and text alone. For each attempt, mark the branch taken and the reason: requested person, out-of-scope action, missing subject or absent evidence. If two reviewers choose different branches for the same enquiry, clarify the rule before implementing it. This catches a priority error that polite wording alone would conceal.

Do not use this design for unattended booking changes, sensitive decisions or a promised response deadline. For uncertain document creation, follow the document recipe’s failure and retry guidance. The teaching tree establishes no channel delivery, agent availability or conversation success benchmark.