There's a WhatsApp chatbot for restaurants I've been running in production for months for a Madrid restaurant I work with. It's not a demo or a prototype: it talks to real guests, checks the dining room's real availability, and creates real bookings in the restaurant's reservation system. The owner pays €49 a month to keep it running.
This post is the no-marketing version: exactly what it does, what it cost to build, what broke along the way (several things), and the cases where I would NOT recommend building one. If you're considering a WhatsApp booking bot for your restaurant, this is what I wish I'd read before starting.
What the bot actually does
Day to day, the bot covers four fronts:
- Frequently asked questions. Opening hours, address, whether there's a terrace, whether kids are welcome, how to get there from the metro. 60-70% of incoming messages are variants of this, and the bot resolves them in seconds, at any hour — including Sunday at 11:40 pm.
- Real bookings. Not a "we'll call you to confirm": the bot checks live availability in the restaurant's reservation system (Tableo, in this case) and creates the booking directly — name, phone, party size, time. The guest gets the confirmation in the same chat.
- Managing existing bookings. Find your reservation, cancel it, or modify it — always locked to the phone number you're writing from. Nobody can touch someone else's booking, and before executing any change the bot confirms with you what it's about to do.
- Handing off to a human. When the conversation goes off-script — a complaint, a group of 25, an allergy menu — the bot says so clearly, notifies the team, and steps aside. More on this below, because it was one of the expensive lessons.
And one thing it does from the very first message: disclose that it's an automated assistant. It doesn't pretend to be a waiter. Besides being the honest thing to do, in the EU it's mandatory: any AI system that interacts with people has to disclose it.
What it really costs
The real numbers from this project, unpolished:
| Item | Cost |
|---|---|
| Monthly fee the restaurant pays | €49/month |
| WhatsApp API cost (Meta) | ~€0/month at their volume |
| AI model cost | Cents per month |
| Reservation system (Tableo or similar) | They already paid for it before the bot |
How can the WhatsApp API come out at ~€0? Because Meta charges for business-initiated template conversations, but replying within the 24-hour window after a customer messages you is free. A support-and-bookings bot lives almost entirely inside that window. The AI model (I use Gemini Flash) costs fractions of a cent per message.
In other words: the running cost is close to zero. What costs money is building and hardening it — weeks of development work, integration with the reservation system, testing with the owner, and the fixes after every failure that showed up in production. The €49/month covers maintenance, tuning the bot's behaviour, and having someone (me) watching when something goes sideways.
Compare that with SaaS chatbot platforms, which run €100 to €300+ per month for plans full of features a restaurant never uses. The difference here is that the system belongs to the restaurant, connected to their reservation system, speaking in their voice.
What went wrong (and what I learned)
This is the part no vendor tells you. Three real production failures:
1. The bot went silent because of an API quota. During the first weeks, the AI model key was on the free tier. A booking bot makes 3 to 5 model calls per customer message (understand, check availability, draft the reply), so one day of heavy testing exhausted the daily limit... and the bot stopped answering without warning. The owner typing, the bot silent. Lesson: a production bot needs paid billing on the model API and alerts when something fails. There is no serious bot on a free tier.
2. The closed Monday the bot ignored. The restaurant closes on Mondays. A customer wrote on a Monday asking for "a table for tonight" and the bot, instead of saying it was closed, started asking for how many people. Why? Language models have conversational momentum: if the conversation is about booking, they keep booking. The fix wasn't "improve the prompt" (that helps, but doesn't guarantee anything): it was adding a deterministic guard — plain ordinary code that checks the day of the week before letting the bot query availability. If it's a closing day, there's no call to the reservation system, full stop. General rule: anything that must never fail doesn't get left to the AI.
3. The bot that said "I'll pass you to a person" without passing you to anyone. The prompt told the bot to escalate to a human when it didn't know something. And the bot said it... but nothing happened, because saying it executes nothing. A customer sat waiting for a person who never came. The fix: turn escalation into a real tool the bot invokes — when called, the system notifies the team, marks the conversation as "handled by human", and the bot genuinely stands down. Same lesson again: the bot's promises have to be backed by code.
The human stays inside the system
The bot doesn't replace the floor staff; it removes their noise. The design that works:
- The bot handles the repetitive (hours, standard bookings, simple changes).
- Everything else — complaints, large groups, unusual requests — escalates to a person, with an explicit notice to the guest that a person will take over.
- The owner has a dashboard where they see every conversation and can step into any of them, at any time.
- The bot's behaviour (tone, hours, which days it closes, what to do with large groups) is edited from that dashboard, without touching code. Change the text and the next message already follows the new rule.
That last point matters more than it looks: a restaurant changes hours in summer, closes for holidays, adjusts the menu. If every change needs a developer, the bot dies of neglect within three months.
When NOT to build a WhatsApp chatbot
Being honest, there are restaurants I'd tell no:
- If you get few messages. With 5-10 WhatsApps a day, whoever's on shift answers them in the quiet moments. Automation pays off when the volume actually hurts.
- If you don't have a reservation system with an API. Without one, the bot can only "take a note" and someone has to enter the booking by hand — you lose half the value. Reservation system first, bot second.
- If nobody will keep the information up to date. A bot giving out winter hours in August does more damage than having no bot.
- If your current WhatsApp number is sacred and you don't want to touch it. Connecting a number to Meta's API has implications for how you use the WhatsApp Business app on the phone. There are ways to make them coexist, but they need planning before, not discovering after.
What I'd tell a restaurant owner
The value of this system isn't "having AI". It's that the phone stops ringing unanswered, bookings come in on their own outside opening hours too, and your team looks after the guests in front of them instead of the phone. And the running cost — €49/month in this real case — is less than one table for two.
But it only works if it's built with the deterministic guards, the real human handoff, and the maintenance I've described. A half-built bot answers badly, and in hospitality answering badly is expensive.
If you run a restaurant and want to know whether this makes sense for your specific case — your message volume, your reservation system, your team — book a 30-minute call with me. No commitment: I'll tell you honestly whether it's worth it for you, or not yet.
Related reading
Frequently asked questions
In the real case described in this post, the restaurant pays €49/month as a running-and-maintenance fee. The underlying technical costs are minimal: Meta's WhatsApp API comes out at ~€0 at restaurant volume (replying within the 24-hour customer window is free) and the AI model costs cents per month. The real cost sits in the initial build and the reservation-system integration, which is a project measured in weeks.
Yes, if the restaurant uses a reservation system with an API (Tableo, CoverManager and similar). The bot checks live availability, creates the booking with name, phone and party size, and confirms in the same chat. It can also find, cancel, or modify bookings, always locked to the phone number of the guest writing. Without an API-enabled reservation system, the bot can only take notes and loses half its value.
No, and it shouldn't try to. The right design has the bot resolving the repetitive work (hours, standard bookings, simple changes) and escalating everything else to a person: complaints, large groups, special requests. The team sees every conversation in a dashboard and can step in at any moment. The bot must also identify itself as an automated assistant from the first message — in the EU that's mandatory.
From my production experience: exhausted API quotas that silently mute the bot, the model's "conversational momentum" (continuing to book on a day the restaurant is closed), and human handoffs the bot promises but never executes. All three are fixed the same way: with deterministic code backing the model — paid billing with alerts, a closed-day check before any availability query, and a real escalation tool that notifies the team.