In February 2024, a Canadian tribunal ordered Air Canada to honor a bereavement discount its chatbot had invented. The airline argued the bot was "a separate legal entity responsible for its own actions." The tribunal disagreed, and the case became the canonical example of what happens when an AI keeps talking past the point where it should have handed off. A grieving customer asking about bereavement fares is high-emotion, policy-sensitive, and money-adjacent. That conversation should never have been resolved by a bot alone.

Most teams deploying AI support get the technology roughly right and the boundary wrong. They can build a bot that answers questions. What they can't articulate is the rule for when the bot should stop answering. This post is that rule - a decision framework for the deflection vs escalation boundary, and for the handoff mechanics that determine whether escalation actually works.

Deflection Rate Is a Cost Metric Pretending to Be a Success Metric

The number every vendor pitches is deflection: the percentage of tickets the AI handles without a human. It's seductive because it maps directly to headcount math. It's also the easiest metric in customer support to game.

A bot that stonewalls customers until they give up "deflects" them. A bot that answers a different question than the one asked "deflects" them. A bot with no escalation button at all achieves 100% deflection by definition. Ryan Wang put it bluntly: a chatbot bragging about 80% deflection is often bragging about 80% of customers who stopped asking, not 80% of problems that got solved. The industry has started correcting for this - DevRev's analysis of ticket deflection draws the same line, arguing the real target is autonomous resolution: the issue is verifiably fixed, not merely absorbed.

The gap between deflection and resolution is where trust dies. Gartner's survey work found that 64% of customers would prefer companies not use AI in customer service at all, and the top cited fear was exactly this: that AI would make it harder to reach a human. Your customers are not anti-AI. They are anti-trap.

Klarna is the cleanest case study of the full arc. In early 2024 the company announced its AI assistant was doing the work of 700 agents. By mid-2025, its CEO publicly admitted the cost-first push had degraded service quality and the company began recruiting human agents again, landing on a hybrid model. The lesson isn't that the AI failed - it handled enormous volume well. The lesson is that maximizing deflection as a standalone goal produced worse outcomes than pairing AI coverage with a deliberate human escalation path.

Key takeaway: if your primary AI support KPI is deflection rate, you have already designed the incentive that will wreck your CSAT. Measure resolution and satisfaction; treat deflection as a byproduct.

The Three Signals That Should Trigger Escalation

Every escalation policy we've seen work in production reduces to three signal families. You need all three, because each catches failures the others miss.

1. Confidence signals (the AI doesn't know)

This is the machine-readable case. Escalate when:

  • Retrieval returns weak matches: the knowledge base has nothing above your similarity threshold for this query.
  • The model's answer conflicts across retries, or a verifier/critic step flags the draft answer as unsupported by retrieved sources.
  • The conversation loops: the customer rephrases the same question a second or third time, which is behavioral evidence that the answers aren't landing regardless of what the model's confidence score says.

Loop detection deserves emphasis because it's the cheapest and most reliable confidence signal available. A model can be confidently wrong; a customer asking the same thing three times is never a good sign.

2. Sentiment and intent signals (the customer is done)

  • Explicit requests: "let me talk to a person," "agent," "representative." Honor these immediately and unconditionally. Making a customer say it twice is the single fastest way to convert a support ticket into a churn event.
  • Frustration markers: profanity, all-caps, sarcasm, escalating message frequency, or a sentiment classifier trending negative across turns.
  • Emotional context: bereavement, medical issues, job loss, fraud victimhood. These conversations have stakes the customer feels even when the dollar amount is small.

Robylon's analysis of email escalation makes a point that applies across channels: the resolve-vs-route decision should weigh emotional load as heavily as topical complexity, because an accurate answer delivered to a furious customer still reads as a brush-off.

3. Stakes signals (the business can't afford a wrong answer)

This is the category the Air Canada case sits in, and it's the one teams most often forget to encode explicitly:

  • Money above a threshold: refunds, credits, disputed charges past a limit you set per customer tier.
  • Policy exceptions: anything where the correct answer is "it depends and someone must decide," like bereavement fares, out-of-warranty goodwill, or contract terms.
  • Legal and compliance exposure: threats of chargebacks or lawsuits, regulated topics, data deletion requests.
  • Revenue at risk: cancellation intent from a high-value account, downgrade requests, renewal-window complaints. An AI can process a cancellation flawlessly and still lose you $40k of ARR a human would have saved with one conversation.

Notice that stakes-based escalation has nothing to do with whether the AI could answer. It often can. You escalate anyway because the cost of a confident wrong answer is asymmetric.

Putting It Together: A Routing Matrix You Can Ship

Here's the framework as a decision table. The two axes are AI confidence and stakes; sentiment acts as an override on top.

Low stakes High stakes
High AI confidence AI resolves autonomously AI drafts, human approves before send
Low AI confidence AI asks one clarifying question, then escalates Immediate escalation with full context

Then two overrides that beat everything in the table:

  1. Explicit human request → escalate, always.
  2. Negative sentiment trending down across two or more turns → escalate, even if confidence is high and stakes are low.

The top-right cell is the one most teams skip and the one that generates the most value. "AI drafts, human approves" gives you 80% of the speed benefit on high-stakes tickets with none of the Air Canada risk. The human reviews a proposed refund or policy answer in 30 seconds instead of composing it in 10 minutes. This is also the cell where you accumulate the labeled examples that later justify moving specific intents into full autonomy.

On thresholds: start conservative. Set the confidence bar high enough that your first month escalates more than it strictly needs to, then loosen it intent by intent as your weekly review of transcripts shows which categories the AI handles cleanly. Tightening a threshold after burning customers is expensive. Loosening one after proving reliability is free.

Counter-intuitive but true: your escalation rate should probably go up in month one of an AI deployment, not down. The AI surfaces demand that customers previously never bothered to submit. Industry statistics on AI support agents consistently show hybrid AI-human models outperforming both pure-bot and pure-human setups on satisfaction, and hybrid means escalations are happening, on purpose, by design.

The Handoff Is Where Escalation Programs Actually Fail

Deciding to escalate is the easy half. The handoff is where the customer experience is won or lost, and it's where most implementations are embarrassing.

The failure mode everyone has personally experienced: you spend eight minutes explaining your problem to a bot, it finally transfers you, and the human opens with "How can I help you today?" Every piece of context is gone. The customer's mental math is immediate: the bot was a toll booth, not a helper.

A production-grade handoff transfers four things:

  • The full transcript, not a summary generated by the same model that just failed. The agent needs to see exactly what the customer said and exactly what the bot promised.
  • The AI's trace: what it retrieved, what it tried, why it escalated. "Escalated: refund request over $500 threshold, customer sentiment negative, order #8841 retrieved" tells the agent where to start. A blank ticket tells them to start over.
  • Cross-channel history. If the customer emailed yesterday and is in chat today, the agent should see both. Support memory that fragments by channel forces customers to re-litigate their own history, and it's one of the most common root causes of "the bot was useless" complaints that were actually handoff failures.
  • Account context: plan, tenure, lifetime value, open tickets. Stakes-based routing only works if the receiving human can see the stakes too.

There's also an incentive problem worth naming. If your AI support vendor charges per resolution, every escalation is a billing event lost, and the vendor's optimization pressure quietly leans toward keeping customers in the bot. Per-resolution pricing puts the vendor's revenue in direct tension with your customer's exit route. When you evaluate tooling, ask specifically: what does an escalation cost me, and what does it cost the vendor? Flat-fee or ownership models remove that tension; usage-priced deflection engines do not.

What to Measure Instead

Replace the deflection dashboard with five numbers:

  1. Autonomous resolution rate - issues verifiably fixed by AI alone, confirmed by the customer or by absence of a reopen within 7 days.
  2. Escalation precision - of the conversations the AI escalated, what fraction did the human agree needed a human? Low precision means thresholds are too tight; you're paying humans to rubber-stamp.
  3. Escalation recall (sampled) - of AI-resolved conversations, audit a weekly sample: how many should have escalated? This is the metric that catches silent Air Canada scenarios before a tribunal does.
  4. CSAT split by path - AI-only vs escalated. If escalated CSAT is far below AI-only CSAT, your handoff is broken, not your escalation triggers.
  5. Repeat-contact rate - customers who come back about the same issue within a week. This is deflection's shadow: every gamed deflection shows up here eventually.

Review escalated transcripts weekly. It's the same discipline as any other AI workflow: the system improves through structured human review of its edge cases, not through threshold tweaks made in the abstract.

How OpenNash CX Can Help

Everything above is a design problem before it's a technology problem, and it's the design work most AI support deployments skip. OpenNash CX builds custom support agents where the escalation boundary is specified up front, in the design phase, before anything ships:

  • Audit: we map your actual ticket distribution to the routing matrix above - which intents are high-confidence/low-stakes candidates for autonomy, and which belong in draft-and-approve or immediate-escalation lanes.
  • Design: confidence thresholds, sentiment triggers, and stakes rules are written down as explicit policy, with human approval gates on the high-stakes cells from day one.
  • Build: handoffs carry the full trace and cross-channel memory, so your agents see the whole history and customers never repeat themselves between chat, email, and voice.
  • Ownership: you own the deployed system outright, and the pricing model doesn't penalize escalations - so nothing in the stack is incentivized to trap a customer in a bot.

To be fair about fit: if your volume is low and your issues are simple, a platform bot with default escalation settings is probably enough, and you should start there. If your support conversations routinely touch money, policy exceptions, or accounts worth saving, the escalation boundary is exactly where custom design pays for itself. Book a call and we'll map this framework to your ticket data.

The teams that win with AI support in 2026 aren't the ones with the highest deflection rates. They're the ones whose customers stopped dreading the chatbot, because reaching a human - with full context, at the right moment - is a designed feature of the system rather than a defeat it's engineered to prevent.