Design a Chat Bot to Human Handoff

Define what the bot may handle

A bot should have a written scope: the intents it can answer, the actions it can take, and the conditions that require a human. The scope should be based on approved knowledge and a clear risk boundary, not on what the bot can technically generate.

Record the source and version for each answer. If the bot cannot find an approved answer, it should say so and offer a human path rather than improvise. A confident wrong answer is worse than a clear limitation.

Make the human path visible

The customer should be able to ask for a human without hunting for a hidden command. The path should be available at the start and at any point where the bot is stuck. Do not force the customer through a long menu just to reach a person.

State what will happen next: a human will join, the conversation will be queued, or the customer will receive an email. Avoid vague promises such as someone will be with you shortly unless the team can meet that expectation.

Use the specialist service role as a starting point for scope, sources, and evidence.

Pass context, not just the transcript

A transcript can be long and still miss the key facts. The handoff should include the customer's intent, the information already collected, the bot's last answer, the unresolved question, and any verification completed. The human should not have to restart the conversation.

If the bot collected sensitive data, pass only what the human needs and follow the retention and access rules. Do not copy the full transcript into a general queue note.

Handle failed automation

A failed automation may be a misunderstanding, a missing integration, or a customer who changed their request. Record the failure reason and route it to the right owner. Do not label every handoff as a bot failure; some are appropriate escalations.

Review the handoffs by intent and reason. A high rate for one intent may mean the answer is wrong, the menu is confusing, or the action is not available. Fix the cause rather than adding more fallback text.

NIST Privacy Framework provides public guidance that can help your team test workflow assumptions.

Keep ownership after the handoff

The human who accepts the conversation becomes the owner. Record the acceptance and the next action. If no human is available, the bot should not imply that someone is already working on it. Use the approved queue or callback path.

If the customer leaves before a human joins, record the state and the follow-up. A conversation that disappears without an owner is a lost request, not a completed handoff.

Compare this approach with the next related workflow guide.

Pilot one intent

Choose one intent with a clear scope and a safe human path. Measure how often the bot completes the request, how often it hands off, and whether the human receives enough context. Review a sample with the support and product owners.

Expand after the first intent is stable. The goal is a handoff that feels like a continuation, not a restart.

Common questions

Ready to create a clearer support role?

Bring the workflow that consumes the most attention. We will help shape the role, handoff, and review points.