Automating restaurant bookings without losing the personal touch
A lunch service has a rhythm of its own: someone asks for the bill, a couple walks in without a booking, and the phone rings for the third time. Whoever answers it stops looking after the person standing in front of them; whoever ignores it loses a table. That is the real problem, and it is not fixed with more friendliness or more people on shift. It is fixed by deciding which calls and which messages do not need a person behind them.
The moment the phone rings
Bookings do not arrive evenly spread across the day. They pile up in the busiest moments, and every venue has its own: yours will show up in your own log as soon as you start looking at it. In those stretches the phone competes with the bar, with the orders and with the table waiting for dessert. Nobody wins that competition. What actually happens is that some calls go unanswered and others get handled in a rush.
A missed call does not announce itself. It never shows up in the till reconciliation and nobody mentions it at the end of the shift. That is why this problem gets tolerated: it is invisible, and nobody fixes what they cannot see. The first useful thing an automation does, before booking anything at all, is keep a record. Every request is logged in the restaurant's own system, with time, channel and outcome. From then on you can look at what actually happened instead of trusting the feel of the shift.
What can genuinely be automated
Some requests get handled well without a human involved. The first is availability: whether there is a table for two on Thursday at nine is a closed question, with an answer that comes straight from the same system where you already record bookings. The second is confirmation: name, time, party size and a message the guest can show at the door. Neither one gets better because a person says it out loud. They only take up time.
The third is the reminder: a message ahead of the date that the guest can confirm or cancel without having to ring. There is no need to chase: whoever does not reply keeps the table, and whoever cancels does it without the awkwardness of explaining themselves on the phone. You find out about the cancellation earlier, not when it is time to seat everyone. The fourth is a change of time or party size, which is the same availability check seen from the other side.
Then there is the waiting list, which is where automation shows most clearly. When someone cancels at half past seven, the table comes back on the market at the worst possible moment for a person to deal with it. A system can notify, in order, everyone who signed up for that day and time slot, give them a window to reply and move on to the next name if nobody answers. It is mechanical, repetitive work done under time pressure: exactly the profile of what is worth automating.
What a machine should never answer
Some requests look like bookings and are not. A large group is a negotiation: set menu, finishing time, whether there is a cake, whether everyone fits in the same room. A serious allergy is a liability, and whoever takes it on has to be someone from the kitchen, not a generated sentence. A celebration is an expectation the guest has already built in their head, and it is worth hearing in full. A complaint needs someone who can decide on the spot.
The criterion is not technical difficulty. An assistant can draft a reasonable answer about allergens; the problem is that it should not. The useful question is what happens when it gets it wrong. If the cost of the mistake is a booking written down badly, a phone call fixes it. If the cost is someone in the emergency room, a ruined celebration or a guest who leaves angry and tells everyone, that does not get automated even when it can be. Sometimes the answer is not to automate.
The handover is the part that matters
A booking system that works is recognised by how it lets go of a conversation, not by how many it closes on its own. When a word like allergy, coeliac, birthday, group or complaint comes up, the conversation stops being automatic and moves to a person with the full context already written down: who it is, for when, how many and what they have asked for so far. The guest repeats nothing. That detail is the difference between seeming looked after and being looked after.
The handover has to work in the other direction too. If the manager is in the middle of service and cannot reply, the system should say so plainly and give a specific time, instead of leaving the guest waiting in front of a screen. Promising immediate attention at half past two on a Saturday eats away at the very trust the automation was there to protect. An honest message is worth more than an assistant pretending someone is available.
Fitting in with what you already use
If you already have a booking book, a table plan, a till system or a spreadsheet, the job is not to replace them, it is to connect them. On top of that there is the phone with WhatsApp, answered by whoever is free at the time. We build the conversational side on the official WhatsApp API and the logic in n8n or Make, so that it talks to the system you already have.
The official API matters for a practical reason: it is the route Meta sets out for business messages, with templates Meta has to approve before they can be used, rather than leaning on the venue's personal WhatsApp as if it were a bot. Zepai is an Official Meta Partner, and that says how we work the channel, not that Meta supervises your project. If your volume comes as calls rather than messages, a voice agent picks up the phone at any hour, takes the details and leaves them alongside the rest. The rule is the same on both channels: tables get written down in one place only.
What will take longer than you expect
Here is the uncomfortable part. Early on the system gets things wrong in silly ways: it fails to make out a voice note with background noise, it mixes up this Thursday with the next one, or it accepts a booking on a closing day because nobody put it in the calendar. That is not fixed by writing better instructions on day one. It is fixed by reading real conversations and correcting as they come. Anyone selling you something that works perfectly from minute one is selling you something else.
There is a second limit, and it is a business one. If your problem is not the volume of calls but a floor running short of staff, automating bookings will give you room to breathe, but it will not solve the other thing. It is worth looking at where the time goes before building anything. If by the end of the conversation we can see that your bottleneck is somewhere else, we will tell you, even if that means a smaller project or none at all.
How it gets set up
The order we follow is simple. First we look at how bookings come in today and at which moments they get dropped. Then we define, in writing, what the system answers and what it does not, so nobody hesitates when an odd case turns up. After that it is connected to your table system and tested during a real service, with someone watching. Most projects are ready in five to seven working days, depending on the channels and the integrations involved.
When we finish we train whoever is going to use it: how to change opening hours, how to pause the system on a closing day, how to read what has happened. The idea is that you do not depend on us for the day-to-day. We do not publish a price list because it depends on the channels, the volume and what has to be integrated. If you want to see how it would look in your case, write to info@zepaiagency.com or call +34 604 14 09 97: we reply in under 24 hours.
Want to build this in your company?
Half an hour, no sales pitch. And if we think it is not worth it for you, we will say so.
Get a free quote →