Vendors demo the happy path. A clear caller, a simple request, a clean booking. It is a fair demonstration of the common case and a useless guide to whether the thing will work for you, because the common case was never the risk.
The risk is the call where something goes wrong. And something goes wrong on more calls than any vendor will volunteer — a bad line, an accent the model handles poorly, a request outside scope, a caller who wants to argue about an invoice. What determines whether an AI receptionist earns its place is not how it handles the ninety. It is what it does with the ten.
Four rungs. Falling off the bottom should still leave you with a phone number.
The failures worth planning for
Not all failures are the same, and treating them the same is the most common design mistake.
Transcription failure. The agent did not catch the words. Bad line, background noise, a name it has never seen. This is recoverable — ask again, differently.
Comprehension failure. It caught the words and does not know what they mean. “Can you do a Cat 3 backflow test” to an agent scoped for domestic plumbing. Also recoverable, but not by re-asking: the answer is to admit the limit.
Scope failure. It understood perfectly and cannot help. The caller wants a service you do not offer, or an area you do not cover. This is not a failure at all if handled well — it is a fast, honest no, which is worth more than a wasted callback.
Emotional failure. The caller is distressed or angry and needs a person. The words may be perfectly clear. Continuing is the mistake.
Silent failure. The worst one. The agent thought it understood and did not, and books the wrong thing or writes down a wrong number. Nobody knows until a van goes to the wrong address.
Each of these needs a different response, and a system with one generic fallback (“Sorry, I didn’t get that”) handles exactly one of them adequately.
The handoff ladder
The pattern that works is graduated. Do not jump straight to a transfer, and do not loop forever either.
Rung one — re-ask once, differently. Not a repetition of the same question. If “what’s the address” failed, try “can you give me the ZIP first”. Changing the shape of the question changes what the transcriber has to handle, and a five-digit number is far easier to catch than a street name. One retry only. Two is where callers start getting angry.
Rung two — confirm the part it did catch. “I got the street as Meadow Lane but not the house number — is that right?” This is doing two jobs. It salvages partial information, and it signals to the caller that they are being heard, which buys patience.
Rung three — take a callback number and stop. If the details cannot be captured reliably, capture the one thing that makes the lead recoverable. A phone number and a rough description is a lead. A perfectly structured record with a wrong number is not.
Rung four — transfer to a human. During staffed hours this can come earlier. Out of hours it is the last rung, and it should mean a real number that rings, not a queue.
The critical rule: the ladder must never loop. A caller who ends up back at rung one after rung three has been trapped, and that is the experience people describe when they say they hate phone robots.
What a good failure sounds like
Compare two versions of the same failed call.
Poor:
Caller: It’s the apartment over the taqueria on Bridge Street. Agent: I’m sorry, I didn’t catch that. Could you repeat the address? Caller: The apartment over the taqueria. Bridge Street. Agent: I’m sorry, I didn’t catch that. Could you repeat the address?
Two identical failures. The caller has learned nothing except that this is not going to work, and they hang up.
Good:
Caller: It’s the apartment over the taqueria on Bridge Street. Agent: Bridge Street — got that. I’m not going to get the unit number from that, so can I take your cell and the tech will call you about access? Caller: Yeah, it’s 775-555-0134. Agent: 775-555-0134. And your name?
The second call also failed to capture a usable address. But it produced a booked lead, because it recognised what it could not get and pivoted to what it could. That is the difference between a system designed by someone who has listened to calls and one assembled from a template.
The one legal thing to get right
Before the design questions, one operational one that people discover late.
If you are recording calls, the rules on consent vary by state and some require every party to agree, not just you. The FCC’s guidance on call recording is the starting point, and a one-line disclosure at the top of the call handles it in practice.
This matters more than it sounds for escalation specifically, because the recordings are how you diagnose failures. A deployment where you cannot legally review what went wrong is a deployment you cannot improve. Get the disclosure into the greeting on day one rather than retrofitting it after you have three weeks of recordings you are not sure you can use.
The same applies to any recording you pass to a third party for transcription. Establish where it goes and how long it is kept before you sign, not after a customer asks.
The confirmation problem
Silent failures are the expensive ones, and the defence against them is read-back, but read-back has a cost, and most deployments get the balance wrong in one direction or the other.
Read back everything and calls become tedious. Read back nothing and you dispatch to wrong addresses.
The rule we use is: read back anything that costs money to get wrong. In practice that means the phone number, always, digit by digit. The address, always. The time slot, always. Not the caller’s description of the problem, which the engineer will re-establish on arrival anyway.
For some trades the list is longer. On a towing call the location has to be confirmed and then confirmed again, because being wrong by one exit on the interstate is half an hour and a genuinely unsafe wait. On a restoration call the claim number matters as much as the address, because an insurer job with a wrong reference stalls for days.
Read-back also gives you a free quality signal. If callers routinely correct the agent on the same field, that field’s capture is broken and you can fix it.
Out of hours, where it actually matters
The escalation design that works during business hours and the one that works at 2am are different, and this trips people up.
During staffed hours, “transfer to a human” is a real option and can sit high on the ladder. Out of hours it usually is not, and pretending otherwise produces the worst outcome: a transfer attempt that rings out, leaving the caller with nothing after they had already invested three minutes.
So the out-of-hours ladder should be shorter and end differently. Re-ask once. Confirm partials. Capture the number. Then set an explicit expectation — “someone will call you back before nine tomorrow morning”, and make sure that is true, because an expectation you miss is worse than none.
The exception is genuine emergency work. If you run a 24-hour plumbing operation or emergency locksmith service, there is an on-call person and the ladder should reach them fast for anything that reads as urgent. Define urgent explicitly in the script (water, gas, no heat with a vulnerable occupant, locked out with a child inside) rather than leaving it to the model’s judgement.
Designing for the calls you cannot win
Some calls should not be captured at all, and a system that tries to capture everything wastes your time.
Sales calls. Suppliers chasing invoices. Callers well outside your service area. People asking for a trade you do not do. Every one of those that ends up in your callback queue costs a few minutes of someone’s morning.
A well-configured agent gives these a clean, fast no. “We only cover within about twenty miles of the city, so we wouldn’t be able to help with that — sorry.” Ten seconds, no lead created, no callback owed. Across a month this saves more time than most people expect, and it is a feature nobody demos because it looks like the system refusing to work.
What to instrument
You cannot improve the failure path without measuring it, and most deployments measure only the success path. Track these:
Escalation rate by rung. How many calls reach rung two, three, four. If rung one is resolving almost nothing, the re-ask phrasing is wrong.
Abandonment point. Where in the call people hang up. A cluster at one question means that question is badly worded.
Correction rate per field. How often the caller corrects a read-back. High on one field means that capture is broken.
Callback fulfilment. Of the numbers captured at rung three, how many actually got called back. This is the one people never measure, and it is where the leads leak. Capturing a lead you do not act on is a more expensive failure than not capturing it, because the caller expected something.
Transfer success rate. Of attempted transfers, how many connected to a human. If this is below 90% during staffed hours, the transfer path is broken and you are dropping your highest-intent calls.
Review a sample of failed calls weekly for the first month. Not a report — the actual recordings. Ten calls takes twenty minutes and will tell you more than any dashboard.
The rule underneath all of this
An AI receptionist should never be the last line. It is a filter, and filters have a defined behaviour for what they do not catch.
The design question is not “how do we stop it failing”, because you will not. It is “when it fails, what is the worst thing that can happen”, and the answer should never be a lost caller. It should be a captured number, an honest expectation, and a human who follows up.
Get that right and the failure rate stops being the number that matters. Get it wrong and a 95% success rate still loses you work, because the 5% are disproportionately the urgent, high-value calls where something unusual was going on.
Frequently asked
What is a normal failure rate? It depends heavily on your call mix and line quality. Rather than benchmarking against someone else’s number, measure your own for a fortnight and watch whether it falls as the script is tuned. A rate that does not improve after two rounds of changes suggests a scoping problem rather than a tuning one.
Should the agent apologise when it fails? Once, briefly. Repeated apologising reads as a system that knows it is failing and cannot stop.
Can it learn from failed calls? Not automatically, and be suspicious of vendors implying otherwise. What actually happens is that you review failures and change the script or scope. That is a human process, and it is the one that produces the improvement.
Does a failed call still cost me on a per-minute plan? Usually yes, and that is worth modelling. A system that fails slowly (three retries then a transfer attempt that rings out) burns minutes and produces nothing. Cheap-looking pricing plus a bad escalation design is an expensive combination.
Should failures go somewhere separate from normal leads? Yes. Route rung-three captures into their own queue with a callback deadline attached. Mixed into the general lead list they get triaged last, which is exactly backwards: these are the callers who already had a poor experience and are most likely to go elsewhere.
How long before it settles down? Plan for two to four weeks of weekly review. The first week reliably surfaces things nobody predicted — a common caller phrase, a service you forgot to scope, a suburb name the transcriber mangles.
What if a caller just wants a person immediately? Give them one. Immediately, on first request, no negotiation. Systems that resist are the reason people distrust this category.
Want the failure path designed properly rather than left as a default? Tell us how your calls arrive and we will map the ladder against your actual call mix.