Designing a safe chatbot handoff
Human handoff is not an error branch added after the bot is built. It is part of the primary service design: the point where automation preserves context, sets expectations, and transfers responsibility to a person.
Start with the boundary of automation
List what the bot may answer, what it may execute, and what always requires a person. High-impact actions—closing an account, changing ownership, interpreting a medical or legal situation, or approving a financial exception—need stricter controls than explaining a public help article.
A good boundary uses intent, user state, data sensitivity, and consequence. Confidence alone is not enough: a model can be confidently wrong. Explicitly block unsupported topics and provide a useful route forward rather than improvising.
Offer more than one escalation trigger
Escalate when the user asks for a person, when confidence is below a tested threshold, when the same issue repeats, when sentiment indicates distress, when a tool call fails, or when policy requires review. Never make users fight the bot to reach support.
Thresholds should be based on evaluated conversations, not intuition. Measure false containment—cases marked resolved by automation that users reopen—as well as escalation rate. A low escalation rate is not success if it hides unresolved problems.
Set an honest expectation
Before collecting more information, say whether support is live, the expected response window, and what happens if the user leaves. Do not claim “live” or “a specialist will respond shortly” unless a staffed queue and service target support that promise. Outside service hours, offer an asynchronous case and a reference number.
Transfer useful context, not everything
The agent needs the user’s goal, authenticated identity where appropriate, steps already attempted, tool results, error codes, and the user’s preferred outcome. A concise structured summary is easier to scan than a long transcript, but the transcript should remain available when policy permits.
Tell the user what will be shared. Remove secrets, payment data, unrelated personal details, and hidden model instructions. If a summary is generated, label it and let the agent inspect source messages before taking consequential action.
Assign ownership atomically
A handoff must create a durable case before the bot claims success. Store the conversation reference, queue, priority, timestamp, and delivery state. Use idempotency so retries do not open duplicate tickets. If the support platform is unavailable, admit the failure and offer another contact route.
Once a person accepts the case, prevent the bot from continuing to issue conflicting instructions. Define how the conversation returns to automation after resolution, and make that transition visible to both user and agent.
Protect privacy and access
Collect only data needed to resolve the request. Define retention separately for chat transcripts, model diagnostics, and support cases. Restrict access by role and log sensitive record access. If conversations may be used for model improvement, obtain the appropriate consent and provide a clear opt-out path.
Defend against prompt injection in user-provided text and retrieved documents. Summaries and tool calls should treat external content as data, not instructions. Agents should see when information came from an untrusted source.
Design for accessibility and failure
The escalation control must work with a keyboard and screen reader, remain visible at high zoom, and not depend only on color. Preserve focus when chat panels open or close. Provide a non-chat contact channel for users who cannot or do not want to use the interface.
Test dropped connections, duplicate messages, session expiry, agent disconnect, queue closure, translation failure, and a user returning on another device. Recovery should preserve the case without exposing it to another signed-in user on a shared device.
Measure outcomes rather than deflection
| Metric | What it reveals |
|---|---|
| Time to human acknowledgment | Whether the queue meets the expectation shown to users |
| Context reuse | Whether agents must ask users to repeat information |
| Reopen rate | Whether automated or human resolutions last |
| False containment | Whether deflection hides unresolved needs |
| User effort | How many turns and channel changes resolution requires |
Review failed and successful conversations manually with privacy safeguards. Use findings to improve knowledge, tools, routing, and staffing—not merely to make the bot sound more confident.
- Users can request a person at any time
- High-impact intents always follow defined controls
- Queue availability and wait time are truthful
- Context transfer is minimal, useful, and inspectable
- Case creation is durable and idempotent
- Success metrics include resolution and user effort