A chatbot should hand off when continuing the automated conversation is less reliable than involving a person with the right context and authority. The trigger is not simply that the bot has used a certain number of messages. A short conversation can require immediate escalation, while a longer routine explanation may remain appropriate.
This is a proposed service-design framework. It does not describe a deployed chatbot on this site or claim that automated support has achieved a particular resolution rate.
Define what the bot is allowed to do
Separate explaining public information, reading an authorized account status, proposing an action and executing an action. These are different capabilities. A bot that can explain a return process should not automatically be allowed to approve exceptions or alter an order.
For each capability, identify the source of truth, the required identity checks, the action boundary and the fallback. Avoid asking the language model to infer business authority from the tone of the conversation. Authority belongs in the application workflow, not in a confident answer.
Use explicit handoff triggers
| Trigger | Appropriate response |
|---|---|
| Customer asks for a person | Offer a direct human route |
| Evidence is missing or conflicting | State the uncertainty and transfer the case |
| Account access cannot be verified | Stop account-specific disclosure and use the supported verification path |
| Requested action exceeds authority | Explain the boundary and send to an authorized owner |
| Repeated misunderstanding | Preserve context and escalate instead of repeating the same answer |
| Material complaint or unusual exception | Route to a person able to assess the situation |
The trigger list should reflect actual support risks and obligations. It should not force customers to use special phrases or become visibly frustrated before a person is offered.
Make the handoff complete
A useful handoff includes the customer’s task, relevant verified facts, actions already attempted, unresolved questions and any promises made. It should distinguish the customer’s statements from system-verified information. Otherwise an incorrect bot assumption can become a trusted fact in the human queue.
Send only the information needed for the case. Do not copy unrelated conversation history or expose sensitive data to a broader team. The receiving agent should be able to inspect the source record through controlled access when necessary.
Explain the transition to the customer
Tell the customer that the case is moving to a person, what happens next and what response timing is actually supported. If no one is currently available, provide the available channel and a realistic expectation. Do not simulate a live human presence when the case has merely entered a queue.
The bot should not continue issuing contradictory advice after escalation. Define whether it may answer general questions while the case is open and how it recognizes that a human has taken ownership. A clear state transition prevents parallel conversations from creating competing promises.
Test failure behavior before measuring efficiency
Use scenarios with missing order data, conflicting statuses, repeated failed steps, requests for unauthorized actions and explicit human requests. Verify that the bot stops, preserves the right context and reaches the correct queue. A high apparent resolution rate is not useful if difficult cases are silently abandoned.
The AI feature acceptance-criteria guide provides a structure for these checks. The self-service topic guide helps identify the questions that can be answered reliably without account-specific judgment.
Review both unnecessary and missed escalations
Too many handoffs can make automation unhelpful, but too few can conceal unresolved customer problems. Sample conversations from both groups and examine task completion, repeated contact, inaccurate statements and customer effort. Use the findings to improve knowledge, routing or product clarity before merely changing the escalation threshold.
A good handoff policy makes the service more dependable. It lets automation handle bounded tasks while preserving a clear route for uncertainty, exceptions and human judgment.