luckpandaTL;DR: A chatbot human handoff is the moment an AI or rule-based chatbot passes a conversation to a person. A good one fires early (on request, on a sensitive topic, or after the second failed answer), sends the person a short summary plus the full transcript, and tells the visitor honestly what happens next and when.
A chatbot human handoff (also called human handover, escalation or live agent transfer) is the step where a bot stops answering and a person takes over the conversation. It works when three things are designed on purpose: the triggers that start it, the context packet that travels with it, and the message the visitor sees while they wait. Most chatbot platforms give you the switch but not the design. Microsoft Copilot Studio's built-in Escalate topic, for example, only shows a simple message by default, and Google's Dialogflow CX handoff response is just a signal that your own integration has to act on. This guide covers the triggers, the data to pass, the wait, what the main platforms actually do, and the mistakes that make people repeat themselves.
Warm or cold: which transfer type should you use?
Use a warm transfer. Transfer types come from phone support, and the difference is what the receiving person knows before they say a word:
| Transfer type | What the human receives | What the visitor experiences |
|---|---|---|
| Cold transfer | A new ticket or chat with a one-line subject, or nothing | Explains the problem again from the start |
| Warm transfer | Summary, transcript, visitor details, what the bot already tried | Continues where they left off |
Twilio's September 2026 guidance on AI-to-human handoff puts it plainly: escalation "defaults to cold unless someone designs otherwise." In the same piece Twilio cites its own survey figure that 76% of consumers say the human agent they reach has little or no context about their issue. That number is the case for a warm transfer.
A handoff does not have to be synchronous. For a small business without someone watching chat all day, a handoff can mean: the bot collects contact details and the question, flags the conversation, and a person replies by email or phone within a stated time. That is still a handoff, as long as the visitor is told so.
When should a chatbot hand off to a human?
A chatbot should hand off when the visitor asks for a person, when the topic is one a bot should not decide, or when the bot has failed to answer the same question twice. Waiting until the bot has completely given up is the latest, and worst, moment to escalate.
Use this trigger table as a starting set and tune it from your own transcripts:
| Trigger | Example signal | Hand off when |
|---|---|---|
| Explicit request | "talk to a human", "agent", "real person", a "Talk to a person" button | Immediately, every time |
| Repeated failure | Bot's fallback ("I'm not sure I understood") fires on the same question | On the second failure, not the fifth |
| No knowledge match | Question outside the bot's knowledge base (custom pricing, a specific order) | Instead of guessing |
| Sensitive or high-stakes topic | Refunds, cancellations, complaints, legal, medical, payment disputes | Always, by topic rule |
| High-value lead | Bulk order, enterprise plan, request for a custom quote | After capturing contact details |
| Negative sentiment | "This is useless", all caps, repeated question marks | As soon as it is detected |
| Account or identity action | Changing an address, accessing someone's data | Unless the bot has a verified, authorised action for it |
Microsoft documents the same split in Copilot Studio. Implicit triggers fire when the agent cannot find a matching topic or the user types something like "talk to agent" mid-conversation; the agent then redirects to the Escalate system topic. Explicit triggers are topics you mark as needing a human by adding a Transfer conversation node. Twilio's list overlaps: explicit request, high-stakes task category, second failed attempt on the same question, and a detected sentiment shift.
Keep a "Talk to a person" option visible for the whole conversation, not only after the bot fails. Twilio reports that 63% of consumers want an easy way to escalate at any point, but only 47% of brands provide one.
What context should travel with the handoff?
The handoff should carry everything the person needs to reply without asking the visitor to repeat anything: who the visitor is, what they want, what the bot already said, and why it escalated. Write this payload spec before you build the flow.
| Field | Why the human needs it | Example |
|---|---|---|
| Summary (2-3 lines) | Read in seconds; a 40-turn transcript gets skimmed | "Wants 200 printed boxes by 20 Nov, asked for a bulk price. Bot has no bulk pricing." |
| Handoff reason | Tells the person what kind of answer is expected | "Topic rule: custom quote" |
| Full transcript | For detail and to check what the bot promised | All turns with timestamps |
| Visitor contact details | Needed for any reply after the chat closes | Name, email, phone, company |
| Page and source | Shows what they were looking at | /pricing, came from a Google Ads campaign |
| Last topic or intent | Routes to the right person | "Shipping", "Returns" |
| Language | Route to someone who speaks it | "hi", "de" |
| Conversation ID | Links the chat to the CRM record or ticket | A stable ID from the chat system |
Platforms expose some of this out of the box. Copilot Studio passes the full conversation history plus default context variables to the connected engagement hub: va_Scope, va_LastTopic, va_Topics, va_LastPhrases, va_Phrases, va_ConversationId, va_AgentMessage, va_BotId and va_Language. The private note you write in a Transfer conversation node lands in va_AgentMessage. Twilio Flex's handoff payload includes the conversation ID, memory store and profile references, and custom attributes such as order number or plan tier.
The summary matters more than the transcript. Intercom lists a dedicated summary model in Fin's model layer for exactly this reason, alongside a model that detects when to escalate.
How do the main chatbot platforms handle handoff?
Each platform treats handoff differently, and the difference decides how much you have to build. The short version: some give you a full agent inbox, others only raise a flag.
| Platform | What handoff does out of the box | What you still have to do |
|---|---|---|
| Microsoft Copilot Studio | Escalate system topic shows a simple message; a Transfer conversation node sends history and va_ variables to an engagement hub such as Dynamics 365 Omnichannel | Add the Transfer conversation node (agents created in Copilot Studio don't have it by default); connect a hub; customise the chat canvas, or users see "No renderer for this activity" on the demo site |
| Google Dialogflow CX | A "Live agent handoff" response message signals the API caller | Everything else: Dialogflow CX uses the signal only for measurement, does not change session state and imposes no structure on the data |
| Intercom Fin | Hands over inside Intercom's own inbox; Procedures can end in a handoff to a human or a workflow | Configure Procedures and rules; budget for outcomes ($0.99 per resolution or procedure handoff, $9.99 per sales qualification on chat and email) |
| Zendesk AI agents | Escalates to Zendesk agents on messaging, email and voice | Pick the plan; usage is counted as automated resolutions |
Two practical notes come out of that table. First, "supports handoff" can mean anything from a full inbox to a flag your developer must catch, so test it before you rely on it. Second, on outcome-billed products the handoff design changes your bill: Intercom counts a request to speak with a person as the customer asking for more help, which is not a resolution.
What should the visitor see while they wait?
The visitor should see an honest message that says a person is taking over, when to expect a reply, and how that reply will reach them. The wait is where most handoffs lose people, because the visitor cannot tell whether anyone is coming.
Standard Beagle's handoff UX guide splits the journey into pre-handoff, wait and post-handoff, and recommends showing queue position rather than an estimated time, plus an "email me a response" option when the wait is long. For a small team, the rules are simpler:
- Staff online: "Connecting you to Priya from our team. You're second in line." Then show the person's name when they join.
- Staff offline: "Our team is offline until 10:00 IST tomorrow. Leave your email and we'll reply then. Your chat so far is saved." Ask for the email before the visitor leaves.
- Never fake it. Don't promise "an agent will be with you shortly" when nobody is on shift. A clear next-day reply beats a silent queue.
Honesty also applies to who the visitor is talking to. Article 50(1) of the EU AI Act, applicable from 2 August 2026, requires AI systems that interact directly with people to be designed so those people are informed they are dealing with an AI system, unless that is obvious from context. If your website serves EU visitors, label the bot as a bot, and make the switch to a person visible too.
How do you hand back from a human to the bot?
Handing back means returning a conversation to the bot after a person has dealt with the part that needed them. It is useful when the remaining steps are routine, such as tracking an order, booking a slot or answering follow-up FAQ questions.
Hand back only when:
- The person has closed the issue that triggered the handoff, and says so in the chat.
- The bot keeps the full history, including what the person decided, so it does not contradict them.
- The visitor can still reach a person with one click.
If the bot cannot read what the human agreed (a discount, a delivery date), don't hand back. A bot that re-quotes the list price after a person agreed a discount causes more damage than a slower human reply.
What are the most common handoff mistakes?
The most common handoff mistakes are escalating too late, losing context, and promising a person who is not there. Check your setup against this list:
- Fallback loops. The bot says "Sorry, I didn't get that" four times before escalating. Cap it at two.
- Hidden escape hatch. The only route to a person is typing a magic word the visitor has to guess.
- Cold transfer. The person gets a ticket titled "Chat conversation" and opens with "How can I help?"
- No contact capture. The visitor leaves before a person replies and there is no email or phone to follow up on.
- Bot promises it can't keep. The bot quotes a price, a delivery date or a refund that a person then has to walk back. Sensitive topics should go straight to a person by rule.
- No measurement. Nobody reviews escalated conversations. Copilot Studio marks conversations that reach Transfer conversation as Escalated sessions in its analytics; whatever tool you use, read those chats weekly and turn repeat questions into knowledge base answers.
How do you measure whether handoff works?
You measure handoff with four numbers, reviewed weekly: the escalation rate, the time to first human reply after handoff, how often the person had to ask the visitor to repeat information, and how many handed-off leads got a reply at all.
| Metric | How to count it | What it tells you |
|---|---|---|
| Escalation rate | Handed-off chats / all chats | Rising: gaps in the bot's knowledge. Near zero: the bot may be blocking people |
| Time to first human reply | Handoff timestamp to first human message | Whether your stated wait time is true |
| Repeat-ask rate | Handoffs where the person asked for details already in the transcript | Whether the context packet is working |
| Unanswered handoffs | Flagged chats with no human reply after 24 hours | Leads you are losing |
The repeat-ask rate is the one most teams skip, and it is the clearest test of a warm transfer.
How does LuckPanda's chatbot handle handoff?
LuckPanda's Chatbot module is being built and is not live yet. As designed, conversations the assistant cannot handle are flagged for handoff in the All chats view, the visitor is told that a person will follow up, and any contact details or requirement the visitor shares are saved as a lead with a follow-up task in the LuckPanda CRM. The chatbot cannot issue quotes or invoices or take payments; it collects the requirement and a person prepares any quote. See the Chatbot module, how conversations and flagged handoffs will work, and the rules LuckPanda's AI agents follow.
Sources
- Microsoft Learn: Hand off to a live agent (Copilot Studio)
- Google Cloud: Dialogflow CX fulfillment, Live agent handoff
- Intercom Help: Fin AI Agent outcomes
- Intercom Help: Fin AI Agent explained
- Zendesk Help: About AI agents
- Twilio: How to design an AI-to-human handoff that preserves context
- EU AI Act, Article 50
- Standard Beagle: Chatbot handoff UX