AI Receptionist for Restaurants: What It Answers

What a voice assistant on a restaurant line actually does — and what it is not

It picks up, recognises what the caller wants, and does one of four things: reads out an answer that already exists in writing, checks a table against the booking system, writes a booking into that system, or hands the call to a person. That is the whole list. It is not a manager, it is not a salesperson, and it decides nothing the restaurant has not decided in advance.

Everything below rests on one line: the assistant can only answer what you have already written down. A fact that lives in a head — the owner's, the host's, the chef's — is not answerable by anything except that head. So the honest order of work is the reverse of the one people expect: first you write the answers down, then you put a machine in front of them. The product side of this is our voice call reception service; this page is about the method.

Written answer — a fact the restaurant has already fixed in writing: opening hours, address, parking, the allergen list, the deposit rule, the children's policy. Only these can be answered without a person.

Where the AI sits and where a plain routing rule and a database write sit

This distinction is not decoration. Half of what gets sold as "AI on the phone" is a routing table with a synthetic voice on top, and the other half is genuinely a language model doing work no rule could do. A restaurant that cannot tell them apart cannot tell what it is paying for.

Read the middle and right columns as two different bills. The models are the part that varies with usage; the rules and the database calls behave the same on the thousandth call as on the first. The difference between an agent that decides and a bot that follows a script is worked through in the live article on AI agents versus chatbots.

Two cautions travel with that number and must not be dropped: section I is accommodation and food service together, hotels included, and only enterprises with ten or more people.

Four questions that show what you are actually paying for

The table above cannot be read off a vendor's brochure, but it can be rebuilt with four questions asked before anything is signed. Each of them has a checkable answer rather than a declarative one.

1. Which steps of the call are done by a model and which by a rule? "All of it is AI" means either that the person opposite does not know or that they would rather not say. Speech recognition, intent parsing and speech synthesis are models; checking a table, writing a booking and routing a call are queries and rules.
2. Can I change the handover rules myself, without raising a ticket? A rule you cannot reach is somebody else's decision wearing your name. Ask to be shown the screen where it is edited, not to be reassured that it can be.
3. Where does the booking land — in my system, or in a copy held by the vendor? A copy means two sources of truth and a room overbooked on the first busy evening. That difference weighs more than the quality of the voice.
4. What happens when the model is unavailable? A rule should remain: route to a person's number, or say that the line is being handled by hand for now. "That does not happen" is an answer to a different question.

The first two questions are about what you are buying. The last two are about what stays with you when the contract ends.

Closed without a person: the calls whose answer is already written down

The test is mechanical. Take the request, and ask whether the answer exists somewhere in writing that you would be willing to show a guest. If it does, the assistant can say it. If it does not, no assistant can invent it.

The same border applies in text channels — a website chat window answers exactly the facts that are written down and nothing else, which is why the chat assistant and the phone line are fed from one set of answers, not two. When the answers live in two places they drift, and the drift is discovered by a guest.

When a written answer stops being an answer

A written answer is not permanent, and its decay gives off no signal: the assistant will state an out-of-date fact in exactly the same calm voice as a current one. A person on the line would hesitate and check; a machine has nothing to hesitate with. So the list of written answers needs two extra notes against every entry — who maintains it, and when it was last confirmed.

Decay comes in three kinds, and each behaves differently:

• A fact with an expiry date — holiday hours, the closing week, a seasonal change of opening times. You can see in advance when it stops being true, so the date can be written down beside the fact.
• A fact that depends on the kitchen — the allergen list, a seasonal menu, whether a dish is available. It changes without warning, and it is the one category where handing the question to a person can be wiser than maintaining the answer at any cost.
• A fact that changed quietly — a new deposit rule agreed on a shift and written down nowhere. It is discovered by the guest who was told the old version.

One working rule covers all three: an answer with no owner goes stale faster than an answer with no date. A missing date is visible on the list; a missing owner is visible nowhere.

Handed to a person: price, contract, promise, conflict

Four categories, and they are not a matter of taste.

Price that is being created rather than read. A published price is a written answer. A quote for an event is a negotiation, and a negotiation cannot be delegated to a machine with no authority to give anything away.

Anything contractual. Deposits above the standard rule, invoicing terms, corporate accounts, cooperation with a delivery platform.

Any promise about the future. "Will the terrace be open in October", "can you hold the whole room for us". A promise made by a machine is still a promise the restaurant has to keep.

Conflict. A complaint, a refund request, an angry guest. An escalation must never make the guest repeat the whole story to whoever takes over: the transcript goes across with the call, or the handover cost more than it saved.

What has to exist before the assistant takes its first booking

An assistant that writes bookings into nothing is a machine for producing arguments at the door. Five things have to exist first, and none of them are software.

1. A booking system that is the single source of truth. If bookings also live in a paper notebook, the assistant will overbook the room and be blamed for it. This is the job of the booking module: one table of reservations, one place they are written.
2. A written table plan — how many tables, of what size, how long a sitting is assumed to last. Without a sitting length, "is 19:00 free" has no answer.
3. Written rules for the awkward cases: large groups, children, dogs, deposits, late arrivals. Every rule that is not written is an escalation waiting to happen.
4. A confirmation that reaches the guest. Something said on the phone and something recorded in the system are not the same event until the guest sees the second one. The automatic confirmation messages close that gap, and the same channel carries the reminder chain described in the article on no-shows and the confirmation chain.
5. A named person on the other end of the handover. Not "the restaurant" — a role, with a phone that is answered during service.

Two rates that measure this: closed without a person, and handed over

Containment rate — the share of answered calls that ended without a person joining, out of all answered calls.

Escalation rate — the share of answered calls handed to a person, out of the same denominator.

Containment rate % = Calls closed without a person ÷ Calls answered × 100

• Calls closed without a person — answered calls that finished without anyone joining, count from the telephony log;
• Calls answered — every answered call in the same period, same log, same clock.

Escalation rate % = Calls handed to a person ÷ Calls answered × 100

• Calls handed to a person — answered calls transferred, or closed with a callback promise that a person then had to keep.

If your two rates do not add up to a hundred, calls are disappearing between the two counters, and the rate is not the thing to fix first.

There is no published benchmark for either rate in Polish or European official statistics, and this page does not print one. Neither Eurostat nor the national statistical office collects business call handling — no missed-call series, no answer-time series, nothing about which share of calls a business closes itself. What the catalogues hold under "telephone" is household internet telephony and telephone affordability, which measures something else entirely. So the only honest benchmark for your restaurant is your own first month, and the second month compared against it. Where these rates hang in a wider tree of restaurant numbers is set out in the pillar on which restaurant numbers to track.

A third rate is the one owners actually mean when they say "is it working":

Booking capture rate % = Bookings written into the system on the call ÷ Calls with booking intent × 100

• Bookings written into the system on the call — reservations that exist in the system when the call ends;
• Calls with booking intent — calls in which the guest asked for a table, counted by intent and not by total volume.

Say so next to the number, or someone will read it as a percentage of something.

This page does not put money on any of it. The cost of a call that nobody picked up is calculated, with its own formula, in the live article on what missed calls cost a business, and the cost of a booking by channel belongs to a neighbouring page, cost per booking by channel. One page, one arithmetic.

Three ways these two rates will lie to you

The check that they add up to a hundred catches exactly one fault — calls lost between the counters. The three below walk past it without a trace, because the sum still comes out right.

A handover to nobody counted as a closure. A call transferred to a person who was not by the phone ends with the guest hanging up. If the counter only looks at whether anyone joined, that call lands among the ones closed without a person and lifts the rate precisely when the service failed hardest. What settles it is whether the handover was answered, not whether it was started.

Two periods under one line. The numerator from one month and the denominator from another, because the telephony export and the assistant's report cut the day at different hours. The rate then comes out plausible and comparable with nothing, itself a month earlier included.

The night counted into service hours. Calls outside opening hours are easier by construction: they have no human alternative to be measured against, and they are mostly about hours or the address. Poured into one pot they raise the share closed without a person and hide what happens during the dinner rush.

All three are checked the same way: take a handful of calls out of the log and walk them by hand before believing any percentage. Doing it once covers a year, because what is being looked for is a fault in the definition, not in the number.

When the assistant does not understand: a drop into a person, not into silence

Fallback — the rule that fires when the assistant cannot classify a request: hand over, take a callback number, or say plainly that it cannot help.

Failing to understand is not the failure. Failing quietly is. The three acceptable endings to a call the assistant could not classify: transfer to a person now, take a number and a sentence about what the guest wanted, or say "I cannot help with this, here is the direct line". The unacceptable ending is a loop — asking the guest to repeat themselves a third time — and the worst is a cheerful confirmation of something that was never understood.

Write the fallback rule before anything else, and count how often it fires. A fallback firing on one call in three is telling you which answers are still unwritten — the most useful list the first month produces.

A booking taken by phone against a booking taken on the site: who carries it

On the website the guest fills the form themselves, sees what they typed, and gets a confirmation with their own words in it. On the phone the guest says a name and a time out loud, and someone — or something — types it. The error moves from the guest to the line. That is the whole difference, and it decides where the effort goes.

Reading the booking back out loud is not politeness, it is the error check. The written confirmation afterwards turns a spoken agreement into something both sides can look at. Handling all inbound requests as one queue rather than five separate ones is the subject of the article on automating request handling — the phone is one entrance to that queue, not a system of its own.

Languages on the line: why a second language costs less here than in the room

Adding a second language to a dining room means hiring for it. Adding one to a written set of answers means translating a finite list once, and the list is finite by construction — it is exactly the set of facts you wrote down. This is the one place where the phone is genuinely cheaper than the floor.

Two warnings. The assistant must speak the guest's language for the whole call, fallback sentence included: a handover announced in a language the guest does not speak is worse than no handover. And a language you can answer in but cannot escalate in is a trap — if nobody on shift speaks it, the callback promise is empty. The same written answers also feed the messaging channels, so one translation is used in several places.

The first three seconds a caller hears, and why they decide the call

There is no industry norm of three seconds, and this page does not invent one — those seconds are simply the length of the greeting you write yourself. What goes into them is your decision: whether the caller is told they are speaking to an assistant, whether the restaurant's name comes first, whether there is a menu of options or a plain "how can I help".

Say plainly that it is an assistant. A guest who works it out halfway through feels tricked, and the feeling attaches to the restaurant, not to the vendor; a guest told at the start simply speaks more clearly. The other decision belonging in those seconds is the exit: the caller should know from the beginning how to reach a person.

A call outside opening hours: the one case with nothing to argue about

Every argument on this page is about a border. This case has none. At two in the morning the alternative to an assistant is not a person — it is a ringing tone. A call taken at that hour cannot take a table away from a host who is not there, cannot interrupt service, and cannot be worse than the silence it replaces.

That is also why closed hours should be measured separately from service hours. Mixed together they hide each other: the night flatters the containment rate, and the dinner rush drags it down for reasons that have nothing to do with what is written down.

Answered share % = Calls answered ÷ Calls offered × 100

• Calls offered — every inbound call the line received, including those dropped before pick-up. Take it from the telephony export, not from memory.

Split that figure by hour before deciding anything.

What a voice assistant will never know

It does not know that the guest asking for a table by the window is the same person who was there last Tuesday, unless the system was told. It does not know the chef has run out of the fish. It does not know a regular is still angry about something three visits ago. It does not know the group of six is a wedding party scouting the room.

Those things live with people, and this page will not pretend otherwise. What a management layer can do is put the parts a machine does know in front of the people who need them — the subject of the pillar on an AI layer over restaurant management and of the broader overview of what restaurant automation covers. The line is drawn where the written answer stops. It is yours to move, and moving it means writing something down, not buying something.

There is a limit on the other side too. How many calls a line can physically absorb in the busiest hour is separate arithmetic, and it belongs to the neighbouring page on how many calls we can actually take.

Frequently asked questions

What can a voice assistant answer on a restaurant phone line?

Everything the restaurant has already fixed in writing: opening hours, the address and parking, whether a table is free at a given time, and the booking itself. The rule is not about difficulty — it is about whether the answer already exists. A hard question with a written answer is answerable; a simple one without a written answer is not.

What must always be handed to a person?

Four things: a price that is being negotiated rather than read from a published list, anything contractual, any promise about the future, and any conflict. In all four the machine would be creating a commitment rather than repeating one, and it has no authority to do that.

Which part of this is actually AI and which part is a plain rule?

Speech recognition, working out what the caller wants, and speaking the answer are models. Checking whether a table is free, writing the booking, applying your handover rules and counting the results are ordinary database queries and arithmetic. The table earlier on this page splits every step of a call between the two columns.

How do you measure whether the assistant is working?

With the share of answered calls closed without a person and the share handed over, on one denominator, so that the two add up to a hundred. Add the share of calls answered out of calls offered, because a high containment rate on a line that drops half its callers means nothing.

What happens when the assistant does not understand the caller?

It should do one of three things immediately: transfer, take a callback number with a note of what was wanted, or say plainly that it cannot help and give the direct line. Looping back to ask a third time is the failure mode to design out, and confirming something that was never understood is worse than any of them.

What has to exist before an assistant can take a booking?

A booking system that is the only place reservations live, a written table plan with an assumed sitting length, written rules for groups, deposits and late arrivals, a confirmation that reaches the guest, and a named person who answers the handover during service.

Does a voice assistant replace the host?

No, and a restaurant that buys it expecting that will be disappointed on the first difficult call. It removes the repetitive half of the phone — the half whose answers are already written down — so that the person on shift spends their attention on the half that needs a person.

Take one shift and write down the ten things people asked you on the phone. Mark the ones whose answer already exists somewhere in writing. That count is the ceiling of what can come off a person's hands — and the unmarked ones are your work list, in the order the guests gave it to you. More restaurant material is collected in the restaurant section.