What 1 Million AI Voice Calls Reveal for Restaurants and Home Services

Key Takeaways

• Someone else's million calls does not make your own deployment reliable.
• Retry rules and write verification are design choices rather than model features.
• Benchmarks score how a call sounds and measure none of the operations.

Yelp Host passed a million calls this year, which settles the question of whether phone agents work outside a demo. What the announcement describes, though, is how those calls sound.

AI voice agents for restaurants and home services answer the phone, book tables or jobs, take orders, and write the result into the business system. Whether they survive at volume depends less on how natural they sound and more on what the system does when a call fails or a write does not land.

What Yelp and Hatch actually announced

The announcement is a real milestone, and it describes one dimension of the problem.

Yelp and Hatch's announcement put OpenAI's GPT-Live-1 underneath Yelp Host and Hatch in September. The number worth pausing on: since launching in October 2025, Yelp Host has handled more than a million calls for restaurants. Hatch works the other side of the same market, managing what it describes as tens of millions of leads across voice, text, email and web for service businesses.

Now look at what the release says the new model brings. A "full-duplex voice architecture, which enables conversations to include natural pauses, interruptions, and overlapping speech." The ability to "detect the caller's tone, such as excitement, frustration or impatience." Automatic detection and response in "nearly any language." And "sharper post-call transcription accuracy."

Sort those and they all land in the same bucket. Every one is a claim about how the conversation sounds. At a million calls a year, though, things go wrong constantly, and none of those claims says what happens then.

It helps to picture a bad minute at that volume. A table goes into the book for the wrong night. A quote request never reaches the CRM. Neither is a conversation-quality failure, and neither is visible to a caller who hung up thinking it went well. The caller finds out when they arrive, and the business finds out when the caller is already angry.

That is the normal shape of a launch announcement rather than a flaw in the product. It does mean the operating questions live somewhere else, and they are the same ones that decide whether outbound calling actually converts.

Why the phone goes unanswered in the first place

The reason a phone rings out has very little to do with technology.

There is no reliable public number for how many calls a small business misses, so this piece does not quote one. What can be sourced is the pressure underneath. The National Restaurant Association's 2026 outlook reports that nearly three quarters of operators plan to hire and expect difficulty finding experienced managers and chefs. Forty-two percent said their restaurant was not profitable last year.

Put those together and you get a business that cannot easily add a person to answer the phone and cannot afford to lose the booking either.

Home services has the same squeeze with a different trigger. The person who would pick up is under a sink or on a roof. The call arrives while both hands are busy, and the caller is deciding between you and whoever answers next.

So the phone gets handed to software. The decision is bigger than it looks, because it lets an unsupervised system speak for the business.

Neither of those pressures gets solved by a better voice. They get solved by something answering reliably at the moments a person cannot, which is a lower bar than sounding human and a much higher bar than sounding good in a demo.

Retries are a business rule the system has to enforce

Retry policy is a business rule before it is a technical one.

When an outbound call drops for a technical reason, what happens next is not really a model question. The business defines how many times to retry, when, and when to stop. A restaurant confirming a table for tonight has a different answer from a plumber chasing a quote that stays valid for a week.

The technical burden sits underneath that decision. The system has to tell a retryable failure apart from an outcome that should end the sequence. A temporary network problem is worth another attempt. An invalid number, a customer opt-out, or a call that already completed are not, and treating any of those as retryable is how a helpful reminder becomes harassment.

What follows is unglamorous. Configured limits have to be enforced rather than advisory, and duplicate actions have to be prevented so a retry does not create a second booking or fire a second confirmation. Every attempt also has to be recorded, because the only way to know your retry policy is behaving is to read the log of what it actually did.

Home services is where retry policy earns its keep, because the callback is most of the product. A missed quote request becomes a job for whoever calls back first, so the temptation is to set the retry count high and leave it there. The counterweight is that the same setting, applied to somebody who already asked you to stop, is the quickest way to turn a lead into a complaint. That tension is the reason the policy belongs to the business rather than to whoever configured the stack.

The timing side of this shows up in failed delivery rescheduling, where the window for a useful callback closes faster than most teams expect.

Open Source Alternative to Vapi / Retell

Self-hosted voice agent platform — no per-minute fees

dograh-hq/dograh

Star on GitHub

Catching the failures that stay quiet

A booking that never reached the system is worse than a missed call, because nobody knows to chase it.

Our approach to verification is deliberately boring. We rely on the CRM's own response. A success response means the data was written correctly. A failure response means something went wrong, and that triggers a retry rather than a silent shrug. The write is never treated as done just because the call ended well.

Be clear about what that catches. It catches the write failing, the integration timing out, the field rejecting the value. It does not catch a value that was captured wrongly and then written successfully, because from the CRM's side that request looked fine. Anyone offering you certainty about the second case is overselling.

The practical response to that gap is to stop treating the two as one problem. A transport failure is caught by the integration and handled automatically, with no human involved. A content failure is only caught by reading what was actually said, which is a different mechanism with a different cost.

Which is why the second one matters more than it first appears. Once you are past a few thousand calls, nobody is listening to all of them. We run a QA pass that samples a large volume of transcripts and identifies calls that went off script. Those flagged calls are then sampled by a person, and the agent gets fixed based on what they show.

That loop is how genuinely new edge cases surface. The escalation rules you write before launch cover the cases you imagined. Volume produces cases nobody imagined, and those only surface when a machine is reading every transcript.

What to do when you are not sure of the language

The risk here is confidence rather than capability.

Automatic language detection is genuinely useful, and it is also somewhere a system can be wrong without knowing it. The rule we hold to is that an agent should never continue confidently in a language it may have identified incorrectly.

When language confidence is low, the agent asks a short clarification first. It offers the most likely choices and switches only after the caller confirms. That exchange costs a few seconds and removes an entire class of failure where somebody is answered fluently in the wrong language.

After the confirmation the decision tree is short. If the agent supports the selected language reliably, the conversation continues. If support is limited, or confidence stays low, or important information cannot be confirmed, the safest action is a transfer to a qualified person.

When live transfer is unavailable, the agent collects only the minimum necessary information, if it can, and arranges a callback in the caller's preferred language. A default language has a narrow role in all of this. It is there to run the clarification, and it does not replace a reliable handoff.

What the benchmarks do and do not tell you

Benchmarks are useful for the thing they measure, which is the conversation.

GPT-Live-1 scores between 94.9 and 97.3 percent on the conversational dynamics portion of the Artificial Analysis speech-to-speech index, the strongest showing in that category. On the aggregate index Gemini 3.8 Live Extended Thinking edges ahead, 82.6 against 81.5. Both numbers are worth knowing, and we went through the current options in more detail in how the realtime voice APIs compare.

Notice what is being scored. Interaction quality, turn-taking, how the model copes with being interrupted. Those matter, and they are why the turn budget is worth defending.

None of it measures retry discipline or whether a write landed. Nothing in it describes what an agent does when it is unsure what language it is hearing.

We build Dograh as an open-source, self-hostable platform, which means those operational surfaces stay yours to configure rather than behaviour a vendor fixed on your behalf. That is the part no benchmark can score for you.

If you are evaluating a phone agent this year, listen to the demo, then ask the four questions a demo cannot answer. What happens when the call drops. How you will know the booking landed. How a bad call gets found next week. What the agent does when it is not sure what language it is hearing. Every one of those answers is configuration, and configuration is where deployments hold up or quietly come apart.