Mike HeapMike is an experienced Product Manager who focuses on all the “non-development” areas of My AskAI, from finance and customer success to product design, copywriting, testing and more.
Table of Contents
- AI-to-human handoff, in more depth
- How AI-to-human handoff works in practice
- When should an AI hand off to a human?
- What does a "good" handoff look like?
- Common misconceptions about AI-to-human handoff
- Myth 1: Handoff is the AI giving up
- Myth 2: You should minimize handoff rate
- Myth 3: Handoff and escalation are the same thing
- Myth 4: The AI should never escalate before trying
- What AI-to-human handoff is NOT, and how it relates to adjacent terms
- How does My AskAI handle AI-to-human handoff?
- FAQs
Last Updated
Created time
May 27, 2026 01:46 PM
Title length (<60)
Author
Ecomm?
Image
Publish date
May 28, 2026
Slug
what-is-ai-to-human-handoff
Featured
Type
Article
Ready to Publish
Ready to Publish
Most teams treat handoff as the AI's failure mode. In our experience running an AI customer-support agent across hundreds of rollouts, handoff is the design itself: the second tier of a two-tier triage system whose entire job is to get the customer to the fastest, best, right answer. Here's how to wire it up, what good looks like, and the four myths that cost teams real CSAT.
AI-to-human handoff is the structured transfer of a live customer conversation from an AI agent to a human, with the conversation history, the customer's intent, and any collected context passed across.
The cleanest way I've found to think about handoff is as the backup tier in a two-tier triage system. The whole job of the system is to get the customer to the fastest, best, right answer.
There are a few reasons the AI might not be the one to deliver that answer (the information isn't in its sources, the data isn't connected, or the customer simply prefers to speak to a person). In each case the goal is the same: route to whoever can resolve the conversation quickest and best. Sometimes that's the AI replying; sometimes that's a person picking it up.
It's worth distinguishing from a few adjacent things up front. Handoff is not the same as escalation: escalation is the reason a conversation needs a human ("this is too complex", "the customer is upset", "this is a refund over our policy threshold"), and handoff is the mechanical transfer that follows it.
Handoff is not the same as transfer-between-humans (that's a helpdesk routing problem). And handoff is not a binary "AI gave up" moment. In well-tuned setups it's a routine, expected event that happens many times a day, and on some support teams it's the majority outcome by design.
Most readers landing here are either configuring handoff rules for a vendor they've already bought, evaluating an AI customer service vendor and want to know whether its handoff is any good, or trying to figure out why their AI is escalating too much or too little. The rest of this post answers all three by the time we get to how we handle it ourselves.
AI-to-human handoff, in more depth
TL;DR: Handoff has three layers: trigger (what fires it), transfer (what context moves), and post-handoff state (what the AI does afterward). Most vendor documentation collapses them. We don't, because that's where operators tune the wrong knob.
The cleanest mental model is to break handoff into three layers: the trigger (the signal that fires it), the transfer (what context moves with the conversation), and the post-handoff state (what the AI does after the human takes over).
Most vendor documentation and most generic explainers collapse these into a single event. That's why so many handoff configurations go wrong: operators tune the trigger without thinking about what payload arrives at the human's inbox or whether the AI is supposed to stay involved afterward.
Microsoft's Bot Service documentation is the cleanest outside-the-vendor articulation of the second layer. Their handoff protocol is centered around a
handoff.initiate event whose body carries two things: "the context of the handoff request, to route the conversation to an appropriate agent" and "a transcript of the conversation, so an agent can read the conversation that took place between the customer and the bot before the handoff was initiated" (per Microsoft's Bot Service handoff docs).The event includes a
value object the receiving system uses to route, plus attachments for the transcript. Microsoft also defines a status event that comes back the other way (accepted, failed, completed), so the bot knows what happened. Vendor terminology diverges immediately around it. Microsoft uses "handoff". Zendesk Advanced AI uses "escalation block" (the visual element in its dialog builder where the operator wires up where the conversation goes).
Intercom Fin uses "human handover" or "human takeover", and has a dedicated Fin Escalation Router model behind the decision. Gorgias uses "Handover Topics"; Decagon uses "escalation paths" defined inside an Agent Operating Procedure.
Freshdesk Freddy markets "smart escalation to human with full context", and our feature is literally called Chatbot-to-Human Handoff.
An AI escalating a refund-over-some-dollar-threshold decision mid-conversation is a handoff (control passed). Voice and chat differ: Zendesk's voice handoff routes a call to a human via omnichannel with transcript, summary, and intent landing in Agent Workspace, per Zendesk's escalation-strategies documentation. Async channels (email) complicate the post-handoff-state layer because the customer isn't waiting in real time, so the AI's silence-vs-copilot decision matters less.
How AI-to-human handoff works in practice
TL;DR: Six steps from trigger to post-handoff state. The shape is consistent across every major vendor. The configuration surfaces and the post-handoff defaults are where they differ, and that's what an operator should be comparing.
The full process runs in six steps. We've stress-tested this shape against the docs of every major helpdesk AI vendor we research. Where vendors differ is the configuration surface and the post-handoff defaults.
- Trigger fires. The AI detects one of the handoff signals listed in the next section. The customer explicitly asks, the AI's internal confidence on the next reply falls below a threshold, the sentiment classifier flags frustration, an intent classifier matches a human-only topic, a Guidance or routing rule matches, or the conversation enters a repeat loop.
- The conversation is summarized. The AI generates a short summary of what's happened so far: what the customer asked, what the AI tried, why it's escalating, any fields collected (order ID, account email, severity, customer tier). Some vendors lean on a dedicated summarizer model. Intercom Fin runs a fine-tuned 14B Issue Summarizer for this step as part of its seven-model engine (per Intercom's CX Models page). Microsoft Bot Service sends the raw transcript as an
attachmentspayload and lets the receiving system summarize.
- The context payload assembles. Transcript plus summary plus identified intent plus sentiment flag plus collected fields plus, in better systems, a recommended next action for the human. This is the part that determines whether the human is going to have to ask the customer to repeat themselves. If context completeness slips here, the rest of the handoff feels broken regardless of how fast it happened.
- The ticket lands in the right human queue. Routing rules pick the inbox (by intent, by language, by tier, by skill tag). The AI doesn't choose the human; the routing layer does. Intercom routes via Inbox skills-based routing using its Escalation Router decision model (claimed >98% accuracy in Intercom's own marketing). Zendesk routes within the same Zendesk ticket queue and tags handed-off tickets with
escalated_by_ultimate. Gorgias's Handover Topics route to a Gorgias inbox; a community thread notes a practical cap of around ten topics that has frustrated operators (see the Gorgias community discussion on Handover Topics). Our setup lands the conversation inside whichever helpdesk the customer already uses (Intercom, Zendesk, HubSpot, Gorgias, Freshchat, or Freshdesk) via our Chatbot-to-Human Handoff feature. Same ticket, no platform switch.
- The human takes over. First-response SLA clock starts or pauses depending on the helpdesk's configuration. In well-designed flows the customer doesn't notice the change beyond the typing indicator and possibly a "human will reply shortly" message. In poorly-designed flows the customer sees a "transferring..." spinner that lingers long enough to feel like the conversation has been dropped.
- Post-handoff state. Two outcomes. AI silent, where the AI stops replying inside the conversation until the human explicitly reassigns it back (the default for Zendesk, Gorgias, Decagon, Freshdesk Freddy, and us inside the helpdesk). AI copilot, where the AI continues to draft replies for the human to review and send, but does not send on its own. Intercom Fin Copilot keeps Fin available to the human after a handover. Our AI Copilot Chrome extension achieves the same outcome from outside the helpdesk (agents keep using the AI on the conversations that did reach them).
Vendor variation is mostly about which of these steps the operator gets to configure and how the configuration surface looks. Intercom Fin's Guidance accepts natural-language instructions across categories including Escalation, with a limit of 100 active guidance pieces per conversation, up to 2,500 characters each, as documented in Intercom's Fin Guidance best practices.
Decagon exposes the full grid inside Agent Operating Procedures, defined in natural language at setup. Gorgias documents its trigger set explicitly: low confidence, defined handover topic hit, no relevant knowledge found, anger or frustration detected, or explicit customer ask (per the Gorgias AI Agent docs).
We expose the full grid through Handover & Escalation Guidance, one of three Guidance types, each rule a natural-language statement under 75 words; full format in our Guidance docs.
When should an AI hand off to a human?
TL;DR: Seven trigger families. Most production setups combine four to six of them. The art is in the order and the interaction. Escalate too eagerly and the cost benefit goes; escalate too late and CSAT erodes.
There are seven trigger families across the consensus of vendor documentation and the published cross-vendor breakdowns (Cognizant, Kommunicate, OutSystems, Spurnow, Gorgias). All seven should be configurable in a properly-exposed operator surface.
Trigger | What fires it | Example | Tunable? |
Explicit ask | Customer types "speak to a human", "agent please", or any locale variant | "Can I talk to a person?" | Yes, phrase list per locale |
Low confidence | The AI's internal confidence on the next reply falls below a threshold | AI doesn't recognise the SKU the customer is asking about | Yes, threshold per intent |
Sentiment / anger | Sentiment classifier flags frustration or abuse | "This is ridiculous, I want a refund" | Yes, severity band |
Policy / compliance | Conversation matches a regulated intent (legal, fraud, medical, financial advice) | "I want to dispute a chargeback" | Yes, keyword + intent match |
Value / risk | Refund size, account tier, or SLA risk crosses a threshold | Refund over $500 | Yes, per dollar / per tier |
Intent classifier | Specific intents pre-marked human-only | Account closure, account compromise, contract renegotiation | Yes, per-intent toggle |
Loop detection | Customer says the same thing twice, or the AI repeats itself | "I already told you this" | Yes, repeat-count threshold |
Most production setups we see combine four to six of these. The art is the order and the interaction. Escalate too eagerly and the cost benefit goes; escalate too late and CSAT erodes.
We find it helps to group the seven triggers into four underlying buckets the customer-side surface actually maps onto. User request covers Trigger 1; sentiment covers Trigger 3; AI can't answer covers Triggers 2 and 6 (the system reports it can't continue); topic classification covers Triggers 4, 5, and parts of 6 (tag-based or semantic-classification rules that mark certain intents human-only). Loop detection (Trigger 7) is its own thing, on the customer-side too: the customer is signaling that the AI is repeating itself.
Cognizant's analysis lands on a similar four-trigger frame (stall, complexity, empathy, high-value) and is worth reading for its commentary on language cues. They name intensifiers like "always", "never", and "every time" as escalation tells; the full piece is Cognizant's chatbot-to-human handoff timing breakdown.
The vendor exposure varies. Many platforms expose only part of the grid to the operator: Intercom's Fin exposes confidence plus explicit; Decagon exposes the full grid; Gorgias caps practical Handover Topics at around ten, which frustrates operators with longer topic lists. Our Handover & Escalation Guidance feature exposes the full grid as natural-language rules.
What does a "good" handoff look like?
TL;DR: Four metrics matter: time-to-handoff (under 60 seconds is solid), context completeness (transcript + summary + intent), post-handoff CSAT delta (within 5 points of AI-only), and abandoned-handoff rate (under 5%). Zinc hit all four and held 97% CSAT on a 68% AI-resolution mix.
There are four metrics that matter, and none of the consensus-view sources band all four together. Which is why this section ends up doing more work than a typical glossary benchmark write-up.
Tier | Time-to-handoff | Context completeness | Post-handoff CSAT delta | Abandoned-handoff rate |
World-class | <30s | Full payload incl. recommended-next-action | Within 3 pts of AI-resolved | <2% |
Solid | <60s | Transcript + summary + intent | Within 5 pts | <5% |
Average | 60-180s | Transcript only | 5-10 pt drop | 5-15% |
Needs work | >180s or visible "transferring..." loop | Transcript not always available; agent re-asks | >10 pt drop | >15% |
Cognizant's analysis is the right outside-the-bubble corroboration of the time axis. They note that first-contact resolution (FCR) and average handling time (AHT) help distinguish actual performance, and that organizations should "avoid capping bot interactions at three or four turns" as rigid rules in favor of "feedback-driven thresholds that learn when automation is helping". The point: arbitrary turn-count caps are worse than a sentiment-and-confidence-driven trigger model.
The named-customer rollouts we have show what "Solid" looks like in practice. Zinc hit 68% AI resolution with sub-60-second response time (a goal the team had chased for six months) while maintaining 97% CSAT.
The mechanism row in the case study calls out "the human handover feature so AI hands off to people on tougher queries" verbatim. The key reading is that CSAT didn't slip on the cohort that was handed off. That's the one to beat for anyone setting their own bands.
Kriptomat ran 62% AI resolution and saved 172 hours per month using Handover guidance for escalations (the boring-but-effective option). Both examples sit in the Solid band of our table above: context completeness is where they're consistently strong, and time-to-handoff is the lever they tuned.
High-volume / low-AHT teams need faster handoff times (we typically target sub-30s for that band). Complex B2B with named-account ownership tolerates slower handoff but demands richer context. Industry context matters and bands move accordingly.
The table is what we see in customer rollouts and across vendor documentation as of May 2026; we expect to revisit when Zendesk publishes its next State of AI in CX report or when Cognizant releases time-to-handoff numbers specifically.
Common misconceptions about AI-to-human handoff
TL;DR: Four myths that cost teams real CSAT: handoff is the AI giving up, minimize the rate, handoff equals escalation, the AI should never escalate before trying. Each one is wrong for a specific structural reason, and the wrong configuration follows from each.
Myth 1: Handoff is the AI giving up
Our killer counter on this one: "The benefit of having AI in the first place is that humans can react faster to the conversations that are handed over, and they can provide a higher level of care when things are passed to them."
The AI's presence does more than save volume. It speeds up the human's response on the conversations that do reach them, and (this is the part that surprises people) raises the quality of the care given.
The conversations the human picks up arrive pre-summarized, pre-tagged, with the customer's intent identified and the relevant context attached. That's structurally different from the human picking up a cold ticket.
In well-designed setups handoff is a routine, expected outcome (sometimes the majority outcome by design). We've seen teams deliberately keep AI-resolution rates in the 20-30% band and route the rest through handoff with full AI-prepared context, because the resulting human responses are both faster and higher-quality. That's a deliberate design choice; the failure framing doesn't fit.
The opposite failure mode is more telling. When handoff is broken, the customer doesn't get escalated promptly; they get stuck in a loop.
The published Forethought feedback catalogs exactly this (chatbots stuck in conversational loops, "inability to escalate to human agents", customers giving up). The cost of bad handoff shows up as loops; over-eager escalation is the wrong thing to worry about.
Myth 2: You should minimize handoff rate
The right metric is appropriate handoff rate (handed off when handoff was the right call, kept by AI when AI was the right call). The founder framing carries the point: "The goal is to get people to the fastest, best, and right support as quickly as possible. Sometimes that means the AI responds directly to them, and sometimes that means routing to a person." The handoff-rate number itself is meaningless without that frame.
There's a structural reason to be careful with the metric. Intercom expanded its billing model from "resolutions" to "outcomes" in late 2025, keeping the $0.99 unit price but adding Procedure handoffs as a billable event (Intercom blog).
Different vendor pricing models incentivise pushing the rate up or down depending on whose unit is being maximized, which is another reason raw handoff rate is the wrong metric. Tune the triggers; the rate falls out.
Myth 3: Handoff and escalation are the same thing
They overlap heavily, and most teams use them interchangeably. Technically, escalation is the reason ("this needs a human"), and handoff is the mechanism (the transfer).
You can have escalation without handoff (a different AI tier picks up a complex case while still keeping it inside the AI layer), and you can have handoff without escalation (the customer just asks for a human, and there's no problem with the AI's reasoning). The distinction matters most at the configuration surface, where some platforms only expose the escalation reason and infer the handoff mechanism automatically. That can hide bugs.
Myth 4: The AI should never escalate before trying
This is wrong for several trigger families. The founder framing is direct: "Sometimes that might mean immediately passing them to a person."
On explicit ask (Trigger 1), on policy or compliance (Trigger 4), and on value or risk (Trigger 5), escalating immediately is the correct behavior. The AI should not attempt a refund-over-$500 conversation, even if it could.
Vendor documentation backs this up. Intercom Fin's "human-only intent" configuration is built for exactly this case, and Decagon exposes compliance rules inside its Agent Operating Procedures. "Try first, then escalate" is good default behavior for confidence (Trigger 2) and intent (Trigger 6); it's actively wrong for the safety and consent triggers.
What AI-to-human handoff is NOT, and how it relates to adjacent terms
TL;DR: Handoff sits next to five neighboring concepts that operators (and vendor docs) commonly conflate with it. Escalation is the reason; copilot is what the AI does after; sentiment routing is one specific trigger (Trigger 3 above). Live-agent transfer is human-to-human, and bot deflection is the opposite outcome.
Term | What it is | Difference from AI-to-human handoff |
Escalation | The reason a conversation needs a human (sentiment, policy, complexity) | Escalation is the why; handoff is the how. You can escalate to a senior AI tier (no handoff) or hand off without escalating (customer just asked) |
Copilot mode | The AI continues to draft replies after the handoff for the human to review and send | A post-handoff state; one of the two possible handoff outcomes (AI silent vs AI copilot) |
Sentiment routing | Routing a conversation by detected sentiment | A specific trigger family (Trigger 3 in the section above) that feeds into a handoff decision |
Live-agent transfer | Helpdesk function for moving a conversation between two human agents | Transfer is human → human; handoff is AI → human |
Bot deflection | Letting the AI fully resolve a conversation so it never reaches a human | The inverse outcome. High deflection is fine when triggers are well-tuned; "minimize handoff rate" is the misconception version |
These five are the most-confused neighbors we hear in demos. Escalation is the reason and handoff is the mechanism; the post separates them on purpose, even when vendor docs collapse them.
Copilot mode is a post-handoff state (one of two), and operators treating it as a separate event misconfigure the post-handoff layer. Sentiment routing is one specific trigger family within the broader trigger taxonomy. Live-agent transfer is human-to-human and lives entirely on the helpdesk side; bot deflection is the opposite outcome of handoff.
The cluster around handoff is what makes the operator's job tractable: wire up the triggers, choose the post-handoff state, measure the four metrics.
How does My AskAI handle AI-to-human handoff?
TL;DR: Handoff happens inside the helpdesk the team already uses (Intercom, Zendesk, HubSpot, Gorgias, Freshchat, Freshdesk). Triggers are natural-language Guidance rules under 75 words each. After the handoff, the AI stays silent in the conversation but our AI Copilot keeps it useful to the human agent.
In our setup, handoff happens inside the helpdesk the team already uses (Intercom, Zendesk, HubSpot, Gorgias, Freshchat, or Freshdesk). The customer sees the conversation continue in whatever channel they started in. There's no platform switch and no "we're transferring you to our other tool" moment.
The AI summarizes the conversation, identifies the intent, hands the ticket off inside the existing helpdesk, and then stays silent in the conversation until the human reassigns it back. Full detail in our Chatbot-to-Human Handoff documentation.
One of the trigger surfaces is Handover & Escalation Guidance, one of three Guidance types alongside Communication & Style and Context & Clarification. Each rule is a natural-language statement under 75 words ("hand off if the customer asks for a refund over $500"; "hand off when sentiment is negative and the customer mentions billing"; "hand off immediately on any chargeback dispute"). The full seven-trigger grid we walked through in the trigger taxonomy above is exposed; operators don't have to choose from a fixed dropdown of trigger types or wait for a feature request to expand a topic cap. See our Guidance feature page for the full configuration UI.
After the handoff, two things happen. Inside the helpdesk, the AI is silent (it doesn't reply in the conversation until the human explicitly reassigns it back). Outside the helpdesk, the human agent can keep using the AI through our AI Copilot Chrome extension to draft replies as they work, which is exactly the pattern Kriptomat used to save 172 hours per month.
On the measurement side, our Insights feature scores 100% of conversations for AI CSAT (not the usual 2-10% sample), and surfaces handover rates alongside resolution time so the operator can see whether the triggers are firing on the right signals. Voice handoff isn't in scope; we cover written channels only.
The cleanest published example we have is Zinc. They came in with a six-month team goal of sub-60-second response time and hit it overnight after implementing the AI, with 68% of queries resolved by the AI and 97% CSAT maintained.
The case-study mechanism row calls out "the human handover feature so AI hands off to people on tougher queries" verbatim. Sam at Zinc put the goal this way: "At the end of last year I challenged Conrad (CX & Support Leader), how can we provide the same or better service, without hiring anyone?" Conrad's answer was to run the AI on the easy queries and use the handover mechanism to move the harder ones to humans with full AI-prepared context.
The implementation was, in Sam's words, "literally overnight": "The speed of implementation was unreal, we got it live in minutes and the impact was immediate. We forecasted a slow impact, over time, but it was literally overnight."
The same pattern shows up on Kriptomat: 62% AI resolution, 172 hours saved per month, all routed through Handover guidance for escalations, with the AI Copilot Chrome extension keeping the AI useful to the human agents after each handover. That's the helpdesk-native, trigger-on-the-right-signals, AI-copilot-after-handoff pattern we run.
If you want to see the feature surface itself, the Chatbot-to-Human Handoff feature page is the landing point. The Guidance and Insights features sit alongside it as the configuration and measurement surfaces. You can start a free trial and have the whole flow running inside your existing helpdesk in about ten minutes.
FAQs
What is AI-to-human handoff?
AI-to-human handoff is the structured transfer of a live customer conversation from an AI agent to a human, with the conversation history, the customer's intent, and any collected context passed across.
In our framing it's the backup tier of a two-tier triage system whose entire job is to route the customer to the fastest, best, right answer. Sometimes that's the AI replying. Sometimes that's a human picking it up.
What is chatbot-to-human handoff?
Same concept, alternate phrasing. "Chatbot to human handoff" is the more common search-engine phrasing; "AI to human handoff" is the vendor-doc phrasing as the category has shifted from rule-based chatbots to generative AI agents.
The mechanism is the same. Trigger fires, conversation is summarized and packaged, ticket lands in a human's inbox, the human takes over.
When should an AI hand off to a human?
Across vendor docs and the published cross-vendor breakdowns, there are seven trigger families: explicit customer ask, low AI confidence, detected sentiment or anger, a policy or compliance match, a value or risk threshold (refund size, account tier), a specific intent classifier, and loop detection.
Most production setups we see combine four to six of these. The art is in the order and the interaction. Escalate too eagerly and the cost benefit goes; escalate too late and CSAT erodes.
What's the difference between handoff and escalation?
We treat them strictly. Escalation is the reason ("this needs a human"), and handoff is the mechanism (the transfer that follows).
You can escalate without handing off (a different AI tier picks up a complex case but stays in the AI layer), and you can hand off without escalating (the customer just asks for a person, no problem with the AI). Vendor docs frequently use the terms interchangeably; the strict distinction is what makes the operator's job easier to reason about.
What's the difference between handoff and transfer?
Transfer is human → human (one helpdesk agent passing a conversation to another); handoff is AI → human. Transfer is a helpdesk routing problem; handoff is an AI configuration problem.
The two often co-occur (an AI handoff lands a ticket in a queue, and a human agent then transfers it onward to a specialist), but they're separate mechanisms.
What's the difference between handoff and copilot mode?
Copilot mode is a post-handoff state. After the AI hands off, two outcomes are possible.
The AI goes silent in the conversation until reassigned (the default for most vendors including us inside the helpdesk), or the AI continues to draft replies for the human to review and send (Intercom Fin Copilot, our AI Copilot Chrome extension). Copilot mode describes what the AI does after a handoff happens, which is why we treat it as a post-handoff state rather than its own kind of handoff.
What does a good handoff look like?
Four metrics matter. Time-to-handoff (we aim for under 60 seconds once the trigger fires), context completeness (transcript plus summary plus identified intent plus collected fields, all visible to the human without re-asking), post-handoff CSAT delta (handed-off conversations should score within 5 points of AI-only resolved ones), and abandoned-handoff rate (under 5% in solid setups).
Zinc's rollout hit sub-60s response time with 97% CSAT maintained on a 68% AI-resolution mix. That's what Solid looks like in practice.
Why do chatbot handoffs fail?
The most common failure mode is failing open. The customer gets stuck in a loop because the triggers aren't catching the signals that should escalate.
Published feedback on platforms with weaker handoff (Forethought reviews catalog exactly this, with verbatim quotes like "stuck in infinite conversational loops" and "inability to escalate to human agents") shows the pattern. The AI didn't give up too fast; the AI didn't escalate when it should have. The other common failure is context loss: the handoff fires but the human picks up a ticket with no summary and ends up re-asking the customer for information already given.
Should I minimize my AI's handoff rate?
No. The right metric is appropriate handoff rate (handed off when handoff was the right call, kept by AI when AI was the right call).
We've seen teams deliberately keep AI-resolution rates in the 20-30% band and route the rest through handoff with full AI-prepared context, because the resulting human responses are both faster and higher-quality. Tune the triggers (the trigger taxonomy above) and the rate falls out. Minimizing it without context optimizes for vendor invoice line items rather than customer outcomes.
How does Intercom Fin handle handoff?
Fin escalates via a dedicated Fin Escalation Router model (claimed >98% accuracy and part of the seven-model Fin AI Engine) and lands the ticket in Intercom's Inbox using skills-based routing. Triggers are configured through Fin Guidance, with natural-language instructions across categories including Escalation, capped at 100 active guidance pieces per conversation at up to 2,500 characters each.
After the handoff, Fin Copilot continues to draft replies for the human inside Intercom. Note that Intercom's billing now treats Procedure handoffs as a billable outcome at $0.99 alongside resolutions, which matters when sizing the unit economics. For the full picture, see our Intercom Fin guide.
How does Zendesk AI handle handoff?
Zendesk Advanced AI uses escalation blocks placed in its dialog builder. The escalation block can collect data fields, add tags, and update fields before handing off.
Escalated tickets get the
escalated_by_ultimate tag and route via Zendesk's existing skills-based routing. The AI stops on handover by default. On voice, escalation routes the call to a human via omnichannel with transcript, summary, and intent appearing in Agent Workspace. The dialog-builder interface itself has been widely criticized as a frustrating place to configure escalation logic; our Zendesk AI guide covers the trade-offs in more depth.How does My AskAI handle handoff?
Handoff happens inside the customer's existing helpdesk (Intercom, Zendesk, HubSpot, Gorgias, Freshchat, or Freshdesk). Triggers are configured as natural-language rules in Handover & Escalation Guidance, one of three Guidance types, each rule under 75 words.
After the handoff, the AI stays silent in the conversation until reassigned back; the human can continue to use the AI through our AI Copilot Chrome extension to draft replies. Insights surfaces handover rates alongside resolution time so the operator can see whether triggers are firing on the right signals. Voice handoff isn't in scope (written channels only). See the Chatbot-to-Human Handoff feature page for the configuration UI.
