OpenAI published a case study on Ringg's voice agents resolving 65% of customer calls, at 90% lower cost than the previous model.
The cost number matters more than the resolution rate.
We do not build voice agents. We run automation continuously across enrichment, reply classification and deliverability checks for every client account.
The question we ask before automating anything is the one those numbers answer.
Does this workload run often enough, and cheaply enough per run, to deserve an agent instead of a person.
The interesting number is the cost drop, not the resolution rate
An agent resolving 65% of calls sounds impressive alone. It only becomes useful information once you know what each call used to cost.
A 90% drop in cost per call changes which workloads clear the bar for automation at all.
Tasks that were too expensive to automate suddenly pencil out.
Not because the model got smarter, but because it got cheap enough to run on every instance instead of a sample.
Model quality improvements are nice. Cost collapses are what move a task from "someone checks this weekly" to "this runs on every event".
Where we have run the same math
One client's sending fleet runs about 40 domains and 176 mailboxes across Google Workspace and Microsoft 365.
At 15 new prospects per mailbox per day, that is over 2,600 prospects entering sequences daily.
Each one generates replies, bounces and deliverability signals that somebody has to read and act on.
No team checks 2,600 daily events by hand. Reply classification and deliverability checks either run continuously in the background, or they do not run.
That is the threshold Ringg crossed. Once cost per decision falls far enough, you stop sampling and start covering everything, which is the core idea behind our automation engineering work.
Volume is what justifies the agent. Below a certain volume, a person checking a dashboard once a day is cheaper and more accurate than anything you could build.
The 35% still routed to a human is the point, not the gap
An agent resolving 100% of calls would mean either trivial traffic or bad measurement.
The remaining share is where judgment calls, edge cases and anything with real consequence should land.
We see the same split in deliverability.
When a client's sending domains degraded to a health score of 68 and mail started landing in spam, the fix was not an automated rule.
It was a decision to retire those domains and stand up fresh ones, which scored 98 and 100. That call needs someone who has watched a domain burn before.
The automation's job is to surface the 68 fast. Deciding what to do about it stays human.
Confusing those two jobs is how teams either over-automate the parts that need judgment, or pay people to re-check what a script already verified.
Cheaper models tempt you to automate the wrong layer
The obvious move after a cost drop is to push automation deeper into the parts that touch the prospect directly. That is usually the wrong layer to push into first.
We have watched heavily AI-personalized cold email underperform simpler campaigns with tighter targeting.
Prospects recognise machine-written personalization on sight, and cheap generation does not fix a message that reads generated.
A lower cost per call should go toward volume and coverage instead.
Do the boring, high-volume, low-judgment work completely, keep the message simple, and let targeting do what personalization was faking.
What we check before deploying this pattern for a client
Before treating any cost drop as a green light, we want three things confirmed at the client's real volume, not a vendor's demo numbers.
- Whether the accuracy rate holds outside the happy path the case study showcased.
- What the escalation path looks like for whatever does not resolve, and who owns it.
- Whether the money saved goes into coverage and speed, or is quietly pocketed while quality slips.
A cost drop is permission to automate more of what already works. It is not permission to skip checking that it still works at your volume.
The Questions We Get Asked
Does a cheaper model change what we should automate?
Yes, usually by widening coverage of tasks you already automate in a limited way, rather than adding new categories of judgment work. Check the volume math before the model.
Should we build voice agents for our own outbound?
Only if inbound call volume is high enough that cost per call affects your margins.
Most B2B outbound teams are not there, so email and reply classification remain the higher-leverage target.
How do we know when an agent can run without oversight?
When the escalation path for the cases it cannot resolve is as well built as the automation itself.
If nobody owns the exceptions, the agent is not ready, however cheaply it runs.