Voice AI for restaurants: what it should answer, and what it should not

The short version

• Voice AI earns its place on calls with one correct answer, and is dangerous on calls that need judgement about tonight's kitchen.
• A missed restaurant call is not a deferred call, it is a call to the next restaurant on the list.
• The hard part is not the speech, it is writing a correct booking into the reservation system and proving it landed.
• Allergen questions should be refused and transferred by a hard rule in the system, not by a line in a prompt.
• Vendor pricing in this category is usually quoted per location, and sometimes without a stated billing period, so ask before comparing.

What does voice AI do on a restaurant phone line?

It answers the calls that have exactly one correct answer. Are you open on Monday. Can I book four people at eight. Is there parking. Do you do a vegan main. Can I order a collection for half past seven. Those are the calls that interrupt service, and they are the calls a machine can finish without supervision.

The parts are not mysterious. A telephony provider answers the line. Speech recognition turns audio into text. A model works out what the caller wants and what is still missing. Speech synthesis says the reply. Something then writes the result into the reservation system or the till. The speech is the part that impresses people in a demo. The write is the part that decides whether the business got anything out of it.

That is where most pilots quietly fail. A system can hold a natural conversation, say 'that is booked for you', and create nothing. The caller turns up on Saturday with a confirmation they heard out loud and no table. One of those costs more goodwill than a hundred answered calls earned.

So the first question for a vendor is not about the voice. It is: show me the booking appearing in the system, and show me what the call does when that write fails.

Why does the phone still matter if most bookings happen online?

Because the phone now gets the calls the website could not take. Online booking handles the simple case well: two covers, Friday, seven o'clock, no notes. What is left on the phone is the awkward residue. A party of nine, a buggy, a dog, a wheelchair, a birthday cake, a dietary requirement, a question the booking widget has no field for. Those calls also tend to be the higher value ones.

The cost of not answering is not a delay, it is a transfer of business. In a 2025 Harris Poll survey fielded for Hostie, over two thirds of American adults said they would ditch a restaurant that does not answer the phone. The sample was 2,065 US adults and the published margin is plus or minus 2.5 percentage points at 95 per cent confidence, so read it as a firm signal about stated intent rather than as observed behaviour.

Operators are not blind to this. The National Restaurant Association frames its 2026 research around connected technology as the next competitive edge for restaurants. It is a small study, 212 operators surveyed between 18 June and 18 July 2026 plus interviews with eight restaurant leaders, and it reports what operators say they intend to do. Treat that as a direction of travel, not as evidence that any particular product works on your line.

Which calls can it finish alone?

Where does voice AI for restaurants fail?

On the caller's side, mostly. The cases that never appear in a demo are the ordinary ones in production: a caller on a street with a bus going past, a speakerphone in a car, a surname spelled over a bad line, an accent the recogniser handles poorly, a child in the background. None of that is exotic. It is the normal condition of a restaurant phone call.

Modifiers are the second wall. 'Two of the chicken, one without onions, and make the other one spicy but only that one' is a sentence a human handles by asking a single clarifying question. A model will often take the whole thing confidently and get one clause wrong. The fix is not a better prompt. It is reading the order back line by line before anything reaches the kitchen, and accepting that this makes the call longer.

Then there is timing. People interrupt. If the system cannot be cut off mid sentence, callers talk over it and the transcript turns to soup. If it leaves a gap longer than about a second, callers assume the line has dropped and say 'hello' into the silence. Turn taking is the difference between a system people tolerate and one they hang up on, and it is mostly an engineering problem rather than a model problem.

Finally, a decent share of inbound calls are not customers at all. Suppliers, drivers at the back door, recruitment, someone's family. They want a specific person, and the correct behaviour is to route them quickly rather than attempt a conversation about the menu.

Who is responsible when it answers an allergy question wrong?

You are. An allergen answer is not information retrieval, it is a safety claim about what is happening in the kitchen tonight. The system does not know that the fryer is shared, that today's stock was made on a different base, or that the chef swapped a garnish an hour ago. A confident answer there is worse than no answer at all.

So the behaviour has to be refusal and handover: something close to 'I cannot answer that one safely, I will put you through to someone in the kitchen'. Make it a hard rule in the code around the model rather than an instruction inside a prompt. A prompt is a suggestion that degrades under an unusual call. A deterministic check that spots the topic and transfers does not.

The same class covers anything the restaurant would want a person to own: age checks for alcohol, accessibility promises, preparation claims such as halal or gluten free, deposit and cancellation terms for large groups, and anything touching a previous complaint. A short written list of topics the system must never answer is worth more than any amount of tuning.

How much does voice AI for a restaurant cost?

There are two shapes of bill, depending on whether you buy a product or build one. Buying means a licence, normally priced per location, which is the number to watch the moment you have more than one site. Building means a stack of per-minute charges plus the engineering to connect it to your booking system, and the ongoing cost of owning something that answers the phone at half past seven on a Saturday.

On the buy side, published numbers do exist. Slang.ai lists a Premium tier at $599 and quotes enterprise pricing case by case. Its headline figure is shown as 'starting at' with a 'per location' qualifier, and the page does not state a billing period. That last detail is not a nitpick. A price that could be monthly or annual is not comparable to anything until you ask, and it is a fair question to put to every vendor in this category.

On the build side, telephony is the cheapest and most predictable line. Twilio's US programmable voice list, stamped current as of August 2026, charges $1.15 per month for a local number alongside a per-minute rate to receive inbound local calls. Speech recognition, model inference and speech synthesis each add their own per-minute or per-token charge on top. Added up, the running cost of a single call is usually small. The cost that decides the project is integration and maintenance, and that is paid in engineering time rather than in cents per minute.

A rough rule. Buy if you have one or two sites, a mainstream booking platform and ordinary requirements. Build if you have an unusual reservation stack, several brands on one phone estate, a second language that matters commercially, or a rule set no product will encode for you.

What needs to be in place before the first live call?

• •A reservation system you can write to through an API, and a way to confirm the write actually succeeded.
• •Opening hours, closures and last orders held in one place the system reads, not pasted into a prompt once in March.
• •A menu that matches what the kitchen is serving this week.
• •A transfer number a human reliably answers, and a stated rule for what happens when nobody picks up.
• •A written list of topics the system must refuse, allergens first.
• •A greeting that tells the caller they are speaking to an automated system.
• •A decision on recording and retention, taken before the first call rather than after the first complaint.

How do you tell whether it is working?

Three numbers, read weekly, ahead of any dashboard. The share of calls finished without a human. The share of bookings taken by the system that appear correctly in the reservation book. The share of callers who hang up in the first fifteen seconds. The first tells you whether it is useful, the second whether it is honest, the third whether people can bear talking to it.

Then read transcripts by hand. Twenty calls a week, picked without filtering, is enough to find the pattern you did not predict. Every real failure becomes a test case, and that growing set of real calls is the only evaluation that still means something after the model underneath it changes. Vendor accuracy figures were measured on their audio, not on your dining room and not on your customers.

What you will not get is clean attribution to covers. A booking the phone would otherwise have lost is not observable, and a restaurant has too many moving parts in a week to isolate one channel. Say that plainly up front. The defensible claim is narrower and still worth having: calls that used to ring out are now answered, and the bookings they produce are in the book.