An AI Receptionist Needs an Escalation Plan Before a Voice
Teams pick a voice, a script and a phone number first. They find out what the assistant should never handle after it has already handled one wrong.
In short
5 things that decide this
- 01The first design document for a voice agent should list the calls it must not take, not the calls it can.
- 02Three categories need a named route before launch: emergencies, complaints with money attached, and anything with legal weight.
- 03A confidence threshold decides less than teams think. The routing table decides where a call goes once the assistant is unsure.
- 04ZhoopZhoop's voice agents answer inbound calls and book appointments across multiple repair branches, with every call and transcript visible to staff on one dashboard.
- 05An escalation plan with no named person behind it is a diagram, not a system.
The build order gets picked backwards
Most voice agent projects start with the voice. A team picks a text-to-speech model, writes a greeting, tests a booking flow, and demos it. It sounds good, so it ships. Nobody wrote down what the assistant should refuse to do, because refusing was not the exciting part.
That order is backwards. A voice agent answering real calls will eventually hear something it should not resolve. A complaint about a charge, a threat of legal action, a caller who says they are hurt. The document that matters most is the one nobody demos. It is the list of calls this assistant is never allowed to take on its own.
Three categories need a named route, not a smarter model
Teams tend to reach for a better model when a voice agent handles a hard call badly. That fixes the wrong layer. A model can get better at understanding what a caller means and still have no rule for what to do about it. The fix is a routing decision made before launch, not a smarter guess made live on the call.
Three categories cover most of what goes wrong. Emergencies, where the cost of a wrong call cannot be undone. Complaints with money attached, where a caller wants a refund or a cancellation decided on the spot. Anything with legal weight: a threat, a regulator, a lawyer on the line. Each one needs a named destination and a person accountable for answering, agreed with the business before a script gets written.
ZhoopZhoop's inbound agents answer customer calls and book appointments across a multi-branch auto repair business. Staff no longer stop work under a car to pick up the phone. Before any of that ships, one design question gets answered first. Which calls the agent handles, and which ones it hands off the moment it hears them.
- 01Emergencies: transferred immediately, with no attempt to assess how serious the call is.
- 02Money-back complaints: routed to a person who can approve a refund.
- 03Legal or regulatory language: handed off on the first mention, recorded, and flagged for someone to review the next morning.
A confidence score is not a routing plan
A confidence threshold tells you when the model is unsure. It does not tell you where the call should go once it is. Teams tune the number, watch fewer calls trip it, and call the problem solved. That lowers a metric. It says nothing about who picks up once a call is routed away, and that routing table is what makes the metric mean anything.
Build the routing table first, with names attached, not roles. Which number rings for an emergency at 9pm on a Tuesday. What happens if that number does not answer in thirty seconds. Whether a text goes out to a second person at the same time or only after the first attempt fails. None of this is a modelling question. It is an operations question the AI vendor cannot answer for you, because only the business knows who is actually reachable at that hour.
This is why the refuse list is the first artefact of a voice build, before a script or a voice gets chosen. ZhoopZhoop's dashboard shows every call, transcript and booking across every branch. A manager can see what the agent did on an escalated call, not only that it escalated. That visibility turns a routing rule into something a business can actually check.
Questions this raises
01How does an AI receptionist know when to transfer a call to a human?
It matches the caller's words against a list of triggers agreed with the business beforehand. Emergency language, refund requests, legal terms, or a direct request for a person. Detection is set to be over-sensitive on purpose, because an unnecessary transfer costs a few minutes and a missed one costs far more.
02What happens if a call is escalated and nobody answers?
That is where most escalation plans fail quietly. The system needs a fallback: a second number after a set number of rings, then a text to whoever is on call. Add a timestamped record that the call went unanswered. A transfer with no fallback behind it is not a finished escalation path.
03Should the AI try to resolve a complaint before transferring it?
Not where money or a policy exception is involved. The assistant can take the caller's name, order details and what they are asking for. But the decision to refund, waive a fee or make an exception belongs to a person with the authority to make it. Letting the assistant negotiate turns a support call into a liability.
