When a Chatbot Should Hand Off to a Person

A bot should not be measured only by how many conversations it closes. Some requests require a human because the answer is uncertain, the stakes are high, the customer is frustrated, or an authorized action is unavailable. Define those conditions before launch.

Set specific triggers

Use task categories, confidence checks, repeated failed answers, sensitive topics, and explicit requests for a person. A vague 'escalate if necessary' instruction is not an operational rule.

Transfer useful context

Send the original question, what the bot tried, the sources used, and what remains unresolved. Do not make the customer repeat the entire conversation.

Close the loop

Give the staff member ownership and record whether the handoff resolved the request. Use missed and unnecessary handoffs to improve both knowledge and routing.

Write handoff triggers as cases

Include an explicit request for a person, repeated inability to answer, conflicting retrieved information, account-specific action without authorization, and a customer who says the proposed answer is wrong. Define which cases transfer live and which create a ticket, with expected response time and fallback outside business hours. A confidence score by itself is not a business rule. Test each trigger with sample conversations and confirm that the bot stops making claims once the handoff condition is met. The system should be able to say what it knows and what remains unverified.

Write a handoff trigger table with sample conversations. For each trigger, identify the evidence the bot can observe, the safe message it gives the customer, the destination team, and the context packet sent along. Include an explicit human request, unsupported answer, repeated failure, account-specific action, and a sensitive or frustrated exchange. Measure how often a person accepts the transfer and whether the customer has to repeat information. This artifact lets product, support, and engineering agree on behavior before tuning prompts. It also exposes cases where a ticket is appropriate and cases where a live transfer is necessary.

Make context useful to the next person

A handoff packet can include the customer's question, consented identity information, relevant order or case number, sources consulted, attempted steps, and the unresolved decision. Keep speculation labeled as such. The receiving person should be able to continue without asking for the whole story again, while still seeing the original wording when nuance matters. Track whether transferred cases are accepted, resolved, or bounced between teams. Reviewing those outcomes may reveal a missing source document, a bad routing rule, or a workflow the bot should never have attempted.

Decision checklist

• Write the hard-stop topics.
• Test a customer asking for a person directly.
• Design the staff queue and response owner.
• Measure resolution after transfer, not only transfer rate.

A small test before committing

Write five conversations that must reach a person: direct request, repeated failed answer, disputed account detail, commercial exception, and sensitive issue. In a test queue, inspect exactly what the teammate receives and whether the customer must repeat facts. Time the handoff until ownership is accepted. A low transfer rate can be a failure if the bot traps hard cases; measure resolution after handoff and the reasons customers ask for help.

Worked scenario

A hypothetical customer asking for a revised contract term should move to a person with the relevant account and conversation history. The bot can collect context but should not invent a commercial commitment.

For a scoped application of this decision, see AI Agents & Communication Automation.