Knowledge / Field guide
Customer support chatbot handoff: send the context with the customer
A customer who asks for help should not have to repeat their story because a chatbot transferred the conversation. Test the experience from both desks.
2XD Studio · · 2 min read
Choose an escalation signal
A visitor asking for a person is a clear signal. Other triggers may include an unsupported policy question, repeated failed lookups, or a request involving account-specific information. Make the option to request a person visible. Record why the handoff occurred so the support team can distinguish a missing article from an integration failure.
Agree on the handoff packet
Give the rep the conversation, a short summary labeled as machine-generated, the customer's preferred reply channel, and any verified record reference. Keep unverified statements distinct. If the bot only suspects an order match, the human should see that uncertainty before discussing account details.
Run a closed-hours drill
Start a chat after the desk closes. Check what the visitor sees, whether a ticket actually exists, and how the morning team finds it. Set expectations using the real staffing schedule. A promise of an immediate response creates a worse experience than a clear message explaining the next staffed window.
Test transfer quality
Ask a colleague to play a frustrated customer who gives two different order numbers. The handoff should retain the conflict without inventing a verified account. Then ask a rep to take over using only the ticket. Note each detail the customer would have to repeat; those missing details are a concrete backlog for improving the handoff.
Reader questions
Should the chatbot close a ticket after answering?
Only use closure rules that reflect the support team's definition of resolution. Let the customer reopen or request a person.
What metric captures a poor handoff?
Look for repeated contacts about the same issue, missing transcripts, and tickets that arrive in an unowned queue.