A support agent earns its keep on the tickets it hands over. Your routine answers are the easy half. The escalation rules decide whether customers trust the thing at all.
The tempting order runs the other way: tune the answers for weeks, then bolt on a "talk to a human" button at the end. That order produces a bot that bluffs through the one thread that mattered.
This is how we design the line instead. Five questions, each with its own answer, plus the rules that sit underneath them.
Where the line sits
Every incoming message gets one of three routes: answer it, ask a clarifying question, or hand it to a person. Two things pick the route: how sure the agent can be, and what a wrong answer would cost.
| Low cost if wrong | High cost if wrong | |
|---|---|---|
| Grounded answer on file | Answer | Answer, and log it for review |
| Answer is unclear or partial | Ask one clarifying question | Hand to a person |
| No source for the answer | Say so, then hand over | Hand to a person, now |
Read the right-hand column first; consequence outranks confidence. A billing dispute goes to a person even when the agent could quote the refund policy word for word.
When should an AI chatbot hand off to a human?
An AI chatbot should hand off the moment a wrong answer would cost more than a slower one. Speed is what the agent adds. On a high-stakes thread, speed is the wrong thing to optimize.
That test sounds abstract until you apply it to your own queue. Pull fifty recent tickets and sort them by what a confident wrong reply would have done. Most land in "mild annoyance"; a handful land in "lost account" or "legal letter."
Those few set your escalation rules; the rest set your deflection target.
The customers are telling you the same thing. Gartner surveyed 3,566 B2B and B2C customers in February and March 2026. In Gartner's survey, 87% said a company using generative AI for service must give them an option to reach a human agent.
What should always go to a person?
Five categories should go to a person every time, whatever the agent's confidence. They fit an agency's client desk as well as a software company's help desk.
| Trigger | Why the agent stops |
|---|---|
| Cancellation or downgrade | Retention is a conversation. A scripted reply reads as indifference |
| Billing dispute | Money moved, or someone believes it should have. Only a person can decide |
| Legal or compliance concern | Anything the agent says can be quoted back at you |
| A named key account | The relationship is worth more than the minutes saved |
| Repeated failed attempts | The customer has already told you the agent is not working |
These are hard rules, so write them as conditions the agent checks before it drafts a word. A hard rule never sits inside a prompt as a suggestion; it sits outside the model, in code that routes the thread.
Your list will differ at the edges. An agency might add "any mention of a missed deadline." A software company might add "anything about data export." Keep the list short enough that you can read it aloud in one breath.
Hard rules and soft signals: which one decides?
Hard rules decide on their own; soft signals only raise a flag. A hard rule is a condition you can check: the word "cancel," a billing tag, an account on your key list. A soft signal is a pattern that suggests trouble without proving it.
Useful soft signals look like this:
- The customer rephrases the same question twice.
- Replies get shorter and sharper as the thread goes on.
- The thread passes a length you would never let a person run unattended.
- The agent's best-matching source is weak or out of date.
Treat a model's own confidence score as one more soft signal. A model can be confidently wrong, so its self-assessment should never act as a gate by itself.
Soft signals move a thread down the confidence scale. One weak signal might earn a clarifying question; two together, on a thread that touches money or a renewal, should hand over.
The mistake is promoting soft signals to hard rules because they felt reliable in testing. Tone detection misfires on terse customers who are perfectly happy. Keep the hard list for facts.
What happens when a customer says "I want a human"?
When a customer asks for a human, they get one, on that turn. No retention script, no "let me try one more thing." The request is itself a hard rule.
This failure has a name. The Consumer Financial Protection Bureau calls it a "doom loop": a chatbot that keeps a customer circling without an offramp to a human customer service representative. The CFPB's report counts over 98 million Americans, about 37% of the population, who used a bank's chatbot in 2022.
Getting this wrong compounds. Gartner found that only 27% of customers would try a chatbot again after a negative experience. By Gartner's figure, one bad chatbot conversation closes the channel for roughly three in four customers.
Honoring the request is the easy part. The hard part is what the person receives. If your teammate opens the thread and has to ask "what's this about?", the customer has to explain it all again. What belongs in that handoff has its own field note.
How do you stop an AI guessing at a support answer?
You stop an agent guessing by giving it a rule it cannot talk its way around: no source on file, no answer. It says it does not know, then routes the thread.
Most guessing starts upstream, in the help center. Stale articles and two pages that contradict each other give the agent a source to be wrong from. Fix that first, and get the knowledge base ready before the agent reads it. The craft of a good "I don't know" is a design problem of its own, covered in designing refusal.
Two public cases show what the guess costs.
In 2024, a British Columbia tribunal found Air Canada liable after its website chatbot told a grieving customer he could claim a bereavement fare retroactively. The airline argued the chatbot was a separate entity; the tribunal rejected that, per McCarthy Tétrault's summary of the decision. Your agent's answer is your answer.
In April 2025, the support bot for the code editor Cursor told a user that a login bug was a new one-device policy. No such policy existed. Users posted cancellations, and a company representative corrected it about three hours later, as Ars Technica reported.
One bot contradicted a policy that sat on another page of the same website; the other invented a policy that did not exist. Nothing in the design told either one to stop.
Write the rules before the prompt.
Where the escalation rules reach next
The same line runs through every loop.
Your deflection number depends on it. An agent that never escalates posts a flattering deflection rate, because a customer who gives up counts as deflected. Measure the resolution, and read how to measure ticket deflection honestly.
Onboarding carries its own triggers. A new customer stuck on day three is a churn risk wearing a how-to question. See what an onboarding agent should hand over.
Renewals turn soft signals into a timeline. Sharper tickets before a renewal are information, if someone reads them. That is the renewal-risk field note.
Sales has the mirror image of this problem. An inbound reply agent faces the same choice between answering, asking and handing over, on a lead instead of a ticket. See what an AI BDR agent does end to end.
How we build one
A support agent starts with a scope, so put the escalation list in that scope. Name who on your side signs that list off.
Check that your loop should be an agent at all. A queue of fifty tickets a month with no repeat questions may want a better help page and a person. Run it through the five-question diagnostic.
If it clears, the scope names the agent's job, the systems it connects to, the actions it may take, and the test that says it is working. If we can't define that test, we don't take the project. Write the handover list into it too, hard rules included.
Then we roll the build out in stages: shadow mode, then supervised, then autonomous. Decide who reviews the escalations at each stage, and who says the next stage can start. The stages are described in how we roll an agent out.
Mira, the client-success concierge, is designed around this pattern. Her job is to answer the routine questions and route anything past the line to a person, with the conversation and customer history attached. See how Mira handles escalation.
Common questions
Do companies have to disclose that customers are talking to AI?
It depends on where you operate, so tell customers they are talking to AI either way. The rules vary by jurisdiction; check yours with counsel. Say it in the first message. After its support bot invented a policy, Cursor began labeling AI-generated support replies, as Ars Technica reported. Disclosure also makes the handoff read as progress: "I'm passing you to Dana on our team."
Who is liable when an AI support agent gets it wrong?
Plan on it being you, the business that deployed the agent. In Moffatt v. Air Canada (2024), a British Columbia tribunal refused to treat the airline's chatbot as a separate entity, per McCarthy Tétrault's summary. It is a small-claims tribunal decision that sets no binding precedent, and this is not legal advice; ask counsel about yours.
Either way, keep a timestamped record of what the agent said and which source it cited, so you can show exactly what was said. Route anything with legal or financial weight to a person.
What do AI support agents struggle with?
They struggle with anything nobody wrote down, like a manager's habitual exception. They also struggle with a request sitting at the seam of two policies, each true alone, that conflict once combined. That is why the hard rules key on facts you can check, like a billing tag or a cancel request. Anything the agent struggles with belongs on the handover side of the line.
What the call covers
The call runs thirty minutes, free, with no pitch at the end. Bring the ticket types that fill your queue, and the ten that scared you. We will say which ones an agent should answer, and which it should never touch. Book the call here.
Start with the tickets that went wrong.