A message can be answered and booked without a person when three things hold at once: the answer already exists in writing, the reply consumes only a resource the system genuinely controls, and it creates no obligation the restaurant has not already accepted. Break any one of them and the reply stops being an answer and becomes an invention.
Seven messages arrive overnight, and by morning they are not one thing
Overnight the restaurant received seven messages. One person asked whether they could come with a dog. Another wanted a table for six. A third asked about gluten-free dishes. Two wrote about delivery. There was one negative comment. And one person wrote on Instagram: can I have a table for two by the window tomorrow, around 20:00.
One plus one plus one plus two plus one plus one is seven. Trivial arithmetic, worth doing out loud anyway, because in almost every restaurant these seven arrive as one object — "the morning inbox" — and get treated as one. A manager opens the phone at 09:15 and answers them in the order they arrived, which is the worst priority rule available: it puts a question about a dog ahead of a booking that is about to be given to someone else.
They are not one object. They differ on exactly one axis, and it is not the axis people reach for: not length, not politeness, not how hard the message is to read. It is where the answer would have to come from.
Across that whole day, 42 incoming enquiries were handled without anyone on the team touching them.
Either way about a sixth, and it is the sixth that arrives while everyone is asleep, which is precisely why it gets answered late. A guest who writes at 23:40 about tomorrow evening is choosing between you and two other places; by 09:15 the choice has usually been made somewhere.
The line does not run along difficulty, it runs along whether the answer is written down
The rule that suggests itself first is: simple ones to the machine, complicated ones to the human. It fails in both directions, and it fails hard enough to be worth killing before anything else.
"Do you have anything gluten-free?" is six words long and is one of the most dangerous messages on the list to answer automatically. "Table for two tomorrow at 20:00" is longer, duller, and almost perfectly safe. Difficulty of reading and difficulty of answering are unrelated quantities, and the second one is the one that matters.
A written answer is a fact the restaurant has already decided, recorded somewhere specific, and keeps current — the seating grid, the house rules, the dish card, the compensation policy, the guest's own record. Retrieving it is a lookup. Nobody is exercising judgement; someone already exercised it, once, and wrote the result down.
An invented answer is anything produced on the spot to fill a gap in that record. It can be reasonable. It can even be right. But the restaurant did not decide it, and nobody can point to where it came from — which means nobody can correct it, audit it, or reproduce it tomorrow.
Everything below is one idea in different clothes: an automatic reply is safe exactly as far as the written record goes, and unsafe one word further. A system that never invents is not a weaker system — it is the only kind whose answers you can stand behind without reading them first.
Four gates: a test you can run on any message with a pen
Here is the test in a form you can copy into a notebook. Run a message through four gates. All four must pass. One failure sends the message to a person — not as a defeat, but as the right outcome.
Gate 1 — is the answer already written, and is it current?
Not "could someone here answer this", but: is it recorded, in a place that gets updated, and when was it last touched? A rule about dogs written two summers ago, before the terrace was rebuilt, is not a current record. It is a memory with a timestamp.
Gate 2 — does the reply spend a resource the system actually holds?
A table in the grid is such a resource: the system knows how many exist, which are taken, and can take one off the board the instant it says yes. Saturday evening kitchen capacity for a party of 24 is not — no grid contains it, and the only person who knows whether it exists is the head chef.
Gate 3 — does the reply create an obligation the restaurant has not already accepted?
Confirming a table under existing rules accepts nothing new. Naming a price, granting an exception, promising a specific seat, offering compensation — each is a new commitment, and if it is not already written down as policy, no automatic reply may make it.
Gate 4 — if this answer is wrong, what does it cost and can it be undone?
A wrong booking time is annoying and reversible with one phone call. A wrong statement about allergens is neither. This gate does not block risky answers; it decides how much evidence gate 1 has to produce before the reply goes out.
Notice what the gates never ask: how long the message is, how polite it is, how confident the system feels. Confidence is not evidence, and a fluent wrong answer costs more than a clumsy right one, because it does not invite a second look.
The dog, the table for six and the gluten-free menu: three that close themselves, and how each one breaks
These three are the easy end of the list — and each has a specific way of going wrong, worth knowing before you switch anything on.
The dog. Gate 1 decides it. If the house rule is written — dogs on the terrace, not in the room, assistance dogs everywhere — the reply is a lookup and the message closes in seconds. If it is not written, there is no safe automatic answer, because the honest state of the world is that the restaurant has not decided. The failure mode is not a wrong answer but a plausible one: "of course, we love dogs", contradicted at the door by a manager who has been quietly turning them away all summer.
The table for six. Gate 2 passes cleanly: six seats either exist in the grid at that hour or they do not. The trap is gate 3, and it is a threshold. Many restaurants have a rule that starts at some party size — from six a pre-order, from eight a deposit — and six is exactly the size that sits on thresholds. If the threshold is written, the reply applies it and the message still closes itself. If it is not, the system has just confirmed a large table on small-table terms, and somebody will find that out on the night. Whether a deposit belongs there at all is a separate calculation with its own page.
The gluten-free enquiry. This one teaches the whole rule, because it splits down the middle. "Which dishes contain no gluten in the recipe" is written — it is in the dish card, and answering it is a lookup. "Is your kitchen safe for a coeliac guest" is not a fact about the recipe at all; it is a fact about the process — shared fryers, shared boards, the flour that goes into the air when someone dusts a surface at 11:00. Nothing in the dish card knows any of that.
The safe reply answers the written half exactly, hands the other half to a person, and above all does not weld them into one reassuring sentence. "We have several gluten-free dishes, so you'll be fine" is two statements fused, one true and one invented — and the invented one is what the guest will act on.
"A table for two by the window, around 20:00": one message, three promises
The Instagram message is the richest of the seven, because it contains three separate promises wearing one coat.
| what was asked | what it really is | which gate decides |
|---|---|---|
| tomorrow, around 20:00 | a range, not a time | gate 1: the grid works in slots, so the range must be resolved to one |
| a table for two | a resource in the grid | gate 2: the system holds it and can take it off the board |
| by the window | an attribute of a specific table | gate 2 again — and it usually fails |
The first two are ordinary. The third is where automatic replies quietly go wrong. "By the window" is only a resource if window seating is recorded as an attribute of individual tables in the grid. In most rooms it is not: everyone knows which tables those are, and nobody has written it down. If it is not recorded, the honest reply confirms the booking, records the window as a stated preference, and says plainly that it is a preference and not a guarantee.
That gives the sharpest single sentence on this page: an automatic reply may promise only what it can hold. Everything else is recorded as a wish and passed to the room.
The range matters too. "Around 20:00" is not a time; the grid needs one. The reply resolves it — 20:00 if the slot is free, the nearest slot if it is not — and states the resolved time back, because a guest who wrote "around 20:00" and reads "your table is booked" will arrive at whatever hour they had in their head.
And the booking is not the end of the work. The channel it arrived from gets recorded, so that later you can tell what each channel actually costs you — that calculation lives on the cost of a booking by channel. The guest record is updated, a confirmation goes out, a reminder goes before the visit, a follow-up after it. That chain turns a confirmed message into a guest who arrives; without it you have a reservation and a coin flip, which is the subject of the no-show confirmation chain. Running the chain end to end is what a booking module is for, and the messenger side of it is message channel handling.
Two delivery messages and one bad review: the same shape, different rules
Three messages, all of them arriving as complaints or near-complaints, all of them looking alike in an inbox. They divide on gate 3.
"Where is my order?" is a lookup. The order has a status, the status is written, the reply is retrieval. It closes.
"The order was wrong, I want my money back" is not. Money is an obligation, and obligations are gate 3. But here is the lever, and it is the most useful mechanism on this page: writing the compensation policy down converts a judgement call into a lookup. Once the restaurant has decided in writing that a confirmed kitchen delay above a stated threshold entitles the guest to a dessert or a drink on the house, the system can propose exactly that, name the policy it is applying, and ask a manager to confirm. The judgement was made once, in daylight, by the owner — not at 02:00 by a machine guessing what the owner would have wanted.
Note the shape: policy written, system proposes, human confirms. That middle mode — the system organises everything and a person supplies the responsible act — is where a surprising amount of restaurant work belongs, and setting the boundary deliberately rather than discovering it is the subject of the three levels of system autonomy.
The negative comment never closes automatically, and it is worth being precise about why. What can be automatic: the acknowledgement inside a stated time, the routing to whoever owns it, and the gathering of facts around it — booking number, order time, kitchen status, whether a service standard was actually breached. What must never be automatic: any statement about facts nobody has checked, any admission or denial, and any compensation outside the written policy.
There is a second reason to route it rather than answer it. One complaint is an incident; three similar ones are a cause. A system that answers each politely and files it has thrown away the one thing that would have fixed the problem — the pattern across them. Going from a single complaint to the underlying cause is its own discipline, and the public half — who writes review replies and on what deadline — is responding to Google reviews.
A banquet for 24 at 180 PLN a head: the case where the right answer is not to answer
A guest asks for a custom banquet menu for 24 people with a budget of 180 PLN per person. Existing rules do not cover it. This is the message that shows what a system is worth when it cannot answer.
Start with the size of the thing. Twenty-four covers at 180 PLN is 4 320 PLN of commitment sitting behind one message. The window table from the section above, at the day's average check of 170 PLN for two people, is 340 PLN. The banquet carries 12.7 times the commitment of the booking that closed itself in four seconds — and it arrived in the same inbox, in a message of comparable length, between a question about a dog and a delivery complaint. That ratio is the reason the four gates are not about how hard a message is to read.
All four gates fail here, one at a time. Gate 1: no written banquet rule exists at that head-count and that budget. Gate 2: the resource is not a table but a kitchen's evening capacity, and no grid holds it. Gate 3: a per-head price is a new commitment by definition. Gate 4: a quoted price is very hard to take back once a guest has read it.
So the system does not quote. What it does instead is the whole point: it collects the requirements, drafts the proposal, and hands over a task with exactly one thing missing — a price from the kitchen manager.
Why "it went to a person" is not a failure
There is a tempting metric that ruins this: the share of messages closed without human involvement. Set it as a target and you have just instructed the system to answer the banquet, because answering it raises the number. The right measure is not how many messages were deflected but what the human received when one reached them.
Compare two versions of the same enquiry landing on a manager. One: a thread of 17 messages over two days, with the head-count somewhere in message four, the date in message nine, the dietary restrictions in message eleven, and one thing the guest has now had to ask twice. The other: a single task — 24 people, 180 PLN per head, dates offered, requirements listed, draft attached, one missing input named and one named owner for it.
Same enquiry, same guest, same restaurant. The difference is roughly the difference between an hour and four minutes.
What the human gets instead of a thread of 17 messages
The handover format is copyable and needs no software — you can write it on a pad. A task handed to a person carries six things and nothing else:
- What is being asked, in one line, in the guest's terms.
- What is already known, gathered from the thread so nobody re-reads it: numbers, dates, constraints, preferences.
- What is missing, named exactly — not "needs review", but "needs a per-head price".
- Who owns the missing piece, by role.
- The deadline, taken from the guest's timeline, not from ours.
- What happens if nobody decides.
The sixth line is the one most people omit and the one that does most of the work. "If no price is set by Thursday, the party books elsewhere" is a fact about the world; "please review when you have a moment" is a request that competes with everything else on the phone.
What a person should never receive is a conversation. Conversations are for the guest; a colleague gets a decision request. If a thread will not compress into those six lines, that is a signal about the thread, not about the format.
12:40, an anniversary: history changes the answer without changing the rule
At 12:40 a guest calls: it is their anniversary today, and they want a table for two at around seven.
What the room gets is this: table 14, 19:00, anniversary, the guest has visited four times before, and preferred the quiet part of the room. A small task follows — prepare a congratulations card.
Look at what did and did not happen. The rule did not change: a table for two at a normal hour is a plain grid booking, and all four gates pass exactly as they did for the Instagram message. What changed is the inputs. Because the guest has a history, the system knows the seating preference — and because it knows the preference, table 14 rather than any free two-top.
Now put that beside the window seat from earlier. The window could not be promised; the quiet part of the room could be honoured. The difference is not that one preference matters more. It is that one is recorded against specific tables and the other is not. Preferences you have written down are resources. Preferences everybody knows are folklore, and folklore cannot be booked.
That is the practical route into guest history: not a loyalty scheme, but a handful of attributes recorded per table and per guest, which turn into better seating without anyone deciding anything at the moment of booking. What to record and how to segment without inventing categories is guest segmentation in practice; keeping the record is the job of a guest database; and what a voice assistant can and cannot settle on a call has a page of its own, with the front-desk side in reception handling.
"At around seven" is the same range problem as "around 20:00", solved the same way: resolved to 19:00, read back, confirmed.
The guest card is personal data, and the rule that works without a lawyer
"Visited four times, prefers the quiet part of the room, anniversary today, phone number, Instagram handle" is a description of a person. It is personal data, it was collected in the course of taking a booking, and the fact that it makes the service better does not remove any obligation attached to it.
This page deliberately names no article number. A norm you cite by number has to be lifted from the consolidated text and checked against it, and a confidently wrong reference is worse than no reference at all — the reader trusts it and cannot verify it. What follows instead is the part that is stable, practical, and enough to keep an ordinary restaurant out of trouble.
Purpose comes before collection. Write down why you hold each field before you start holding it. "Because it might be useful" is not a purpose; "to seat returning guests where they prefer to sit" is.
Minimum, not maximum. Keep only what changes a decision you actually make. A seating preference changes where the guest sits. A date of birth changes nothing unless you run a birthday campaign — and if you do not run one, do not hold it.
A retention date, written in advance. Records with no end date are kept forever by default, and forever is not a decision anyone made. Pick a horizon, write it next to the field, and make deletion happen without anyone remembering to do it.
Access by role, not by curiosity. A waiter needs tonight's preference, not the visit history, the spend or the notes. Whoever can see everything should be a short written list.
Deletion has to actually work. A guest asking to be removed has to disappear from every place the record was copied to — the booking system, the messenger thread, the mailing list, the export somebody made in March. If you cannot say where the copies are, you cannot honour the request.
Be careful near health. "Gluten-free, please" is a preference the guest expressed, but it sits close to a statement about their health. Record the request as they phrased it; do not record a diagnosis, do not infer one, and do not carry it into anything they did not ask for.
And one rule specific to automatic replies: the system must never repeat back to a guest something they did not tell this restaurant. Knowing more than the guest expects you to know reads as surveillance even when everything was collected properly, and it is the fastest way to lose someone who was about to become a regular. Where customer data physically ends up when you automate anything is worth reading separately, in automation and data protection.
What one message is worth, and how to count the effect without fooling yourself
Now the arithmetic, because "we answer faster" is not a number and nobody should act on it.
Two of the effect lines belong to this page. Recovered and rescued enquiries are worth about 8 000 PLN of revenue a month, and bookings and no-shows about 4 000 PLN of revenue a month. Both are revenue lines, and revenue is not profit — the variable cost of serving those guests has to come off before anything reaches the bottom line.
That first line is easier to trust once you convert it into something countable. At the day's average check of 170 PLN, 8 000 ÷ 170 = 47.1 — about 47 average checks a month, roughly one and a half a day. That is a believable number for messages arriving overnight and at weekends. Reverse it to check: 47 × 170 = 7 990 PLN, back where it started. One honest caveat — it turns money into average checks, not into guests or messages, and a banquet is one enquiry and many checks.
There is a trap in the effect table, and it is the one people fall into when they quote it. Some rows are revenue and some are profit or avoided cost, and the two do not add. Revenue rows: 8 000 + 15 000 + 4 000 + 5 000 + 8 000 = 40 000 PLN. Profit and cost rows: 5 000 + 3 000 + 10 000 + 2 000 = 20 000 PLN. Two separate totals — about 40 000 PLN of additional revenue and about 20 000 PLN of reduced costs and leakage — and printing 60 000 PLN as one figure adds two different quantities into a number that means nothing. Not all of the additional revenue becomes profit, which is why the honest measure is contribution rather than turnover.
The same discipline applies to the campaign side of the guest base, where the numbers are counted per stage rather than per message; that arithmetic lives on winning back lapsed guests, and the day-level version — why a percentage against forecast is not an answer — is on why evening revenue dropped.
One number this page does not print: the share of guest enquiries a restaurant can safely close automatically. There is no published figure for it. We looked — the full Eurostat dataset catalogue, read on 28 August 2026, contains no dataset on enquiry handling or response times at all; its only reservation-related series is about internet use for appointments by level of disability, and its only restaurant series is a price index. The Polish statistical office's labour-market section has nothing either. The absence is not a gap in the search; it is a property of the quantity. The share depends entirely on how much of your own house is written down, which is why the rest of this page is about writing it down rather than about a benchmark.
Writing your own rule table on Monday morning
None of this requires software to start. It requires a table, and the table is the hard part; the software only applies what is already in it.
Take your last twenty guest messages — real ones, from the phone and the messengers, not remembered ones. For each, fill six columns:
| column | what goes in it |
|---|---|
| situation | the guest's request, in their words |
| written answer | what the house rule says, or blank |
| where it is written | the exact place, or blank |
| resource | what confirming it would spend |
| who confirms | nobody, or a named role |
| if wrong | what it costs and whether it can be undone |
Two blanks in the middle columns mean the message cannot be answered automatically today. That is not a verdict on the message; it is a work list. Sort the blanks by how often the situation occurs multiplied by how much it commits you, and fill the top of that list first. Dogs, party-size thresholds and delivery compensation are usually near the top: frequent, cheap to decide, and nobody has ever sat down and decided them.
Do this by hand for a month and you will answer most guests faster than before, with nothing installed. That is the honest claim. What a system adds is that it never sleeps, never forgets a threshold, never gets tired at message nineteen — and does the same thing at three locations as at one, which is a different problem of scale. The rules underneath stay yours, and they are only ever as good as the day you wrote them.
Two things are worth setting up while you are at it. The rules that decide which reply goes out should be an object you can edit and version rather than a habit — that is what a decision rules engine is for — and the messages that go out after the visit, the reminder and the follow-up, are follow-up handling. The difference between a scripted bot and a system that applies written rules is set out in agent versus chatbot; where all of it sits inside a wider management layer is on an AI restaurant management system; and the enquiries that are not bookings at all — weddings, communions, large groups — have their own queue.
Frequently asked questions
Which overnight messages can be booked without a person?
The ones whose answer is already written down and whose confirmation spends only a resource the system holds — normally a table in the seating grid at a stated hour. A booking for two or four at a standard time, under existing house rules, is the clearest example. Everything else is decided by the four gates: written answer, controlled resource, no new obligation, and a cost of error you can live with.
Is a table for six safe to confirm automatically?
Only if your threshold rules are written down. Six is exactly the party size that sits on thresholds — pre-orders, deposits, set menus, a different cancellation window. If the rule exists in writing, the reply applies it and the message closes automatically. If it exists only in the manager's head, an automatic confirmation has just booked a large table on small-table terms, and somebody will find out on the night.
Can an automatic reply say the kitchen is gluten-free?
No, and this is the sharpest example of the whole boundary. Which dishes contain no gluten in the recipe is written in the dish card and can be answered by lookup. Whether the kitchen is safe for a coeliac guest is a fact about process — shared fryers, shared surfaces, airborne flour — and it is not in the card. Answer the written half exactly, hand the other half to a person, and never fuse them into one reassuring sentence.
What should happen to a banquet enquiry that arrives at night?
It should not be answered and it should not be left sitting either. Twenty-four covers at 180 PLN a head is 4 320 PLN of commitment, and no house rule covers a custom menu at that budget. The correct outcome is a prepared task: requirements collected, dates offered, a draft proposal, and one named missing input — a price from the kitchen manager — with a named owner and a deadline taken from the guest's own timeline.
Should a negative review get an automatic answer?
The acknowledgement can be automatic and should be fast; the answer cannot. A system may confirm receipt within a stated time, route the case to whoever owns it, and gather the surrounding facts — booking number, order time, kitchen status, whether a standard was actually breached. It may not admit or deny anything nobody has checked, and it may not offer compensation outside a written policy. It should also keep the case joined to similar ones, because three like it are a cause and one is only an incident.
How do I know whether my restaurant is ready to answer messages automatically?
Take your last twenty messages and try to name, for each, the exact place where the answer is written and how recently it was updated. The proportion you can answer is your readiness, and it is a property of your written rules, not of any software. Most restaurants find the blanks cluster in three places: pets, party-size thresholds, and delivery compensation.
What guest data may an automatic booking store?
Only the fields that change a decision you actually make, each with a written purpose and a written retention date, visible to the roles that need them and deletable everywhere they were copied. A seating preference qualifies. A birth date does not, unless you genuinely run a birthday programme. Requests that touch health should be stored as the guest phrased them and never turned into an inferred diagnosis, and the system should never repeat back to a guest anything they did not tell this restaurant.
Take your last twenty guest messages tonight and mark, for each one, where its answer is written. The blanks are your list — and they are the same list a system would need before it could answer anything on your behalf. The rest of the series on running a restaurant on its own numbers is collected in the restaurant hub.