Every conversation about chatbots eventually reaches the same question: what happens when it cannot help? The answer decides whether customers tolerate the thing or actively resent it.
An escape hatch is not a fallback message. It is a designed path with state, context and an owner.
The four ways a handoff fails
The loop
The bot does not understand, apologises, and asks the customer to rephrase. Forever. There is no counter, so there is no exit.
The fix is one line of state: after two consecutive low-confidence turns, escalate. Not a third apology — escalate.
The amnesia
The customer explains their problem for four minutes, gets transferred, and the human opens a blank ticket. Now they explain it again.
Everything the bot gathered has to travel with the handoff:
- The full transcript
- Every entity it extracted, with confidence
- What it already tried
- Why it gave up
The dead end
"Please contact support" — inside the support channel. The bot offers an action the customer is already taking.
The false confidence
The worst one, because it is invisible. The bot does not escalate at all; it answers, plausibly and wrongly, and the customer finds out days later. No metric catches this unless you are sampling answers against ground truth.
A bot with a 4% escalation rate is not four times better than one at 16%. It is usually the same bot with a lower threshold and a reporting problem.
What triggers a handoff
Confidence thresholds are the obvious trigger and the least interesting one. The rules that matter are categorical:
- The customer asks. Non-negotiable, no confirmation step, no "are you sure?" — it is the fastest way to lose the room.
- Money moves. Refunds, cancellations, plan changes. Draft, do not execute.
- The premise is contradicted. The customer's stated facts conflict with the system of record.
- Sentiment collapses. Not as a tone adjustment — as a routing decision.
- Repeat contact. A second message on the same issue within a window means the first answer did not land.
Note that only the first of these is about the model being uncertain. The rest fire when the model is perfectly confident and the situation is still wrong for automation.
Instrument the hatch, not just the bot
escalation_rate by category, weekly
escalation_reason distribution, not just total
post_escalation_time how long the human then needed
customer_repeat_rate did they come back anyway?
The last one is the honest measure. A resolution the customer returns to argue with was not a resolution.
Say it plainly
When the bot hands off, the customer should be told three things: that it is handing off, why, and what happens next. Not "let me connect you with someone who can help better" — something with information in it:
I can see two charges on your account in March but I can't tell from here whether the second one was a plan change. I'm passing this to the billing team with everything we've discussed. They usually reply within the hour.
That message costs nothing extra to generate and changes how the entire interaction is remembered.