How to design escalation from voice agent to human

1. Decide what triggers an escalation

There are three categories, and they should be configured separately.

The customer asks for it. The simplest and the most important. It should work on the first attempt, however the customer phrases it, and without the agent trying to solve the case one more time first.

The agent is not permitted to do what needs doing. Not "doesn't understand" but "doesn't have the access": a refund above a certain amount, changing a case already under review, anything requiring an authority the agent does not hold. These are known in advance and can simply be listed.

Signals in the call. Third contact about the same case in a short window. Second attempt at the same step. Words like complaint, lawyer, cancel my subscription. In healthcare the category is more concrete still: an emergency call to a dental clinic should have three outcomes, and none of them is a booking dialogue.

Notice that all three are events and phrasings, not readings of mood. That distinction matters now that systems inferring emotion from the voice are high-risk systems. You do not need them either: a customer calling for the third time is a stronger signal than a tone-of-voice score, and one you can explain afterwards.

2. Decide what happens when there is nobody there

This is the point most often missing, and the one that most often generates the complaint.

Outside opening hours, in a queue, or when nobody is logged in – what happens? That assumes the agent knows you are closed at all, but assume for a moment that it does. The worst answer is a transfer to a phone that rings without anyone picking up. The customer has then spent three minutes reaching a human who does not exist. In some sectors that is not a service question but a damage question – in property management the call at half past two in the morning can be a basement filling with water.

Workable alternatives exist: a callback at a time the customer picks, a message with a case number and a promised window, or the agent finishing what it can and stating clearly what is left. Choose one, and make sure the agent knows which one applies right now. If your telephony sits in Teams, the endpoint has already been picked from a dropdown – which is exactly why it is so easy to skip past who actually takes the call.

3. Decide what the agent says as it hands the call over

One sentence, and it should contain three things: that it is happening, who it is going to, and how long it will take.

"I'm putting you through to a colleague in customer service, it'll take under a minute" is enough. "One moment" is not. And do not promise a wait the system cannot hold: an agent that says under a minute and takes seven is worse than one that said nothing.

This connects to the opening. An agent that discloses it is AI and also offers the way out in the opening line itself makes the disclosure harmless. Without the way out, transparency is just a warning.

4. Decide what the human receives

This is where it is settled whether the escalation felt like help.

A customer who has to repeat the whole story to the person concludes the agent was wasted time – however well it performed for the first two minutes. It is the single most common reason an otherwise sound setup gets a bad reputation internally, and it is far from an edge case: nearly half of companies pass nothing at all from the agent to the person taking over.

The minimum that should be ready before the human answers: who is calling, what the case is in the customer's own words, what the agent has already done or looked up, and why it transferred. Four lines. If they are not there, the escalation has not been built.

5. Decide who owns the case if the call drops

Transfers break. Customers hang up in the queue. Connections fail.

The question is what happens then: is there a case left behind that somebody actually sees, or does the enquiry vanish? If it is the latter, the escalation path leaks – and the leak is invisible, because the call was technically answered and gets counted as such.

6. Decide who can change the rules, and how fast

The escalation rules are what you will adjust most in the first months. One threshold sits too low. One case type should have gone straight to a human. Another should not have gone there at all.

If each such change means a ticket with the vendor and a two-week wait, it will not get made. Settle that before you go live, not after.

Try it on three calls before you open

Not on the happy path. On these three:

A customer who asks for a human in the first sentence, before the agent has managed to ask anything.

A customer calling about something the agent has no access to do, at nine on a Friday evening.

A customer who gets transferred, where the connection breaks just as the human answers.

If those three go well, most things will.

Escalation is not a failure state

It is easy to treat escalations as something to drive down. But a low escalation rate can just as easily mean the way out is awkward as that the agent is good, and the two look identical in a monthly report. It is the same problem as containment: the number counts calls that were not transferred, not cases that were resolved.

The goal is not the fewest possible escalations. It is that the ones that happen, happen at the right moment and with enough context for the person to do something about the case. It is also the best answer to the objection that customers would rather speak to a human.

Threll.ai builds voice agents in Norwegian, Swedish and Danish. The part customers remember is rarely what the agent answered. It is what happened when it could not.