Your Voice Agent Books 91% Of Calls. Your Service Drive Runs On The Other 9%.

Every voice-AI vendor selling into service departments this year quotes some version of the same number: a success rate in the low nineties. Ninety-one percent of calls handled successfully. It is a real number — it shows up in industry reliability studies, and it is believable. It is also, on its own, the most misleading number in the category, because a 91% success rate is a statement about the calls that went right, and a service drive does not run on the calls that went right. It runs on what the agent does with the 9% that went wrong.

The arithmetic nobody puts on the slide

A busy franchise service department fields thousands of inbound calls a month. Call it 3,000. A 91% success rate is a wonderful headline, and it also means roughly 270 calls a month land in the failure bucket. That is not noise. That is about nine failed calls a day, and the composition of that bucket is the whole ballgame.

If the 9% is spread across trivial requests — hours, directions, "are you open Saturday" — there is little to worry about. If the 9% is concentrated in the calls that were hardest because they were worth the most — the upset customer whose repair came back wrong, the fleet manager with eight vehicles, the caller ready to approve a large job — then a 91% agent is quietly failing at the exact moments that pay the service drive's rent. Success rate tells you the size of the failure bucket. It tells you nothing about what is inside it.

The pattern that survives production: bounded scope

The deployment pattern that survives contact with production is not "highest success rate wins." It is bounded scope with a designed failure path. The agents that hold up let the AI own the routine 60 to 70% of calls — service scheduling, parts availability, hours, missed-call recovery, follow-up — and hand off fast and cleanly on anything outside that scope.

The number that matters there is not the success rate. It is what happens at the boundary. Does the agent know it is out of its depth, or does it confidently improvise? When it hands off, does the human get the context — who is calling, what they wanted, what has already been said — or does the customer start over from "hi, I'm calling about my car"? A 91% agent with a graceful handoff is a great deployment. A 94% agent that handles its failures by guessing, or by dropping the customer into a dead transfer, is a worse one — and the success-rate column will never tell you which is which.

Design the failure path, not just the happy path

The mistake operators make is treating the failure path as an edge case to be minimized instead of a feature to be designed. It is the opposite. In a service business the failed call is often the high-stakes call — that is why it failed; it was harder, angrier, or more valuable than the routine flow the agent was built for. So the failure path deserves more design attention than the happy path, not less.

• Where does an out-of-scope call go — a named human, a queue, a callback promise the system actually keeps?
• What does that human receive at the moment of handoff?
• And critically: does anyone ever look at the 9%?

"Handled" is not the same as "resolved"

There is a measurement trap underneath all of this, and vendors lean on it. "Handled successfully" and "the customer's problem was solved" are not the same event, and the gap between them lives almost entirely in the failure bucket. An agent can close a call cleanly — polite, on time, no dead air — and still have sent the customer away without a booked appointment, booked the wrong one, or promised a callback no human ever makes. If your success metric is defined at the level of "the call completed without the agent breaking," you will score failures as successes and never see the leak. Define success at the level of the outcome you actually wanted — a booked, correct appointment in your scheduler, a genuine resolution, a completed human handoff — and the headline number will drop, and it will finally be telling you the truth.

We run voice agents across a multi-rooftop deployment, and the single hardest, longest-tuned part of the whole system was never getting the routine calls right. Those came quickly. It was the boundary — teaching the agent to recognize the call it should not try to win, to hand off with the full context attached so no customer repeats themselves, and to route the genuinely valuable-but-hard call to a human fast enough that the value survived the transfer.