WhatsApp automation for restaurants
Your WhatsApp answers, follows up, and fills tables.
The bot handles repeat questions, staff see only what needs a person, and every visit gets followed up.
what time do you close tonight?
- hoursOpen Sunday 12:00 to 22:00.
- menuOur menu lives at serv.example/menu
- parkingStreet parking on Alder, free after 18:00.
Kitchen until 22:30, bar until midnight.
The messages your team answers a hundred times a week
Three moving parts. That is the whole system.
No integrations to babysit, no model to fine-tune, no prompt to debug at 9pm on a Friday.
Setup
Connect your WhatsApp number
The official Meta Cloud API, your existing number, your existing guests. No new app for anyone to download.
Write your rules once
Keyword rules for the questions you already answer daily, and a feedback flow with your own thresholds. Done in an afternoon.
Staff work the queue
The bot handles repeat questions. Your team sees only what needs a person, and every visit gets followed up whether anyone remembers or not.
Never miss a message.
Your team works WhatsApp like a shared inbox. The bot answers the questions you get fifty times a week, and anything it cannot match gets escalated to a human queue instead of vanishing.
Fewer manual replies. Zero silent drops.
matched rule: hours
matched rule: menu
No rule matched
NEEDS ATTENTIONMoved to the staff queue. The bot said nothing, because it never guesses.
Dani took the thread|
HUMANThree conversation modes
AUTO lets the bot reply. HUMAN hands the thread to staff and the bot goes quiet. NEEDS_ATTENTION is the queue for anything unmatched, so nothing sits unread by accident.
Keyword rules you control
Word-boundary matching, priority order, first match wins. No model, no invented menu items. You write the rule, you know the reply.
Official Meta Cloud API
A direct integration, not a scraped or unofficial bridge. Your number stays compliant and stays yours.
Built for more channels
A ChannelAdapter interface sits under the inbox, so Instagram, Telegram and SMS slot in without rewriting the core.
Turn every visit into a review or a save.
Two hours after a logged visit, Serv asks the guest how it went. Food, then atmosphere, two taps each. What happens next depends on the score, and that branch is the whole product.
Every visit becomes a review opportunity or a recovery.
Visit logged
Table closed, guest on file
How was the food?
Then: how was the atmosphere?
Score at or above threshold
Ask for the public review
- Google review link, click-tracked
- Voucher issued automatically
- Reward loop drives the next visit
Score below threshold
Keep it private, fix it fast
- Logged internally as a complaint
- Staff flagged the same day
- Never pushed toward Google
Happy guest, public review
A score at or above your threshold triggers a Google review ask with a click-tracked link, plus a voucher issued automatically. Review generated, return visit booked.
Unhappy guest, private save
A low score never gets pushed toward Google. It lands internally as a complaint and flags your staff while the guest is still winnable.
Flows are JSON, not code
An FSM engine runs template-defined flows, so you can change the questions, thresholds or branches without a deploy.
Timing that is not guesswork
Scheduled in Postgres with pg_cron, decoupled from sending. The visit is logged, the follow-up fires two hours later, every time.
What changes in week one
3
conversation modes
bot, human, needs-attention
2h
after every visit
feedback fires on its own
0
messages dropped
unmatched goes to a human queue
Bring customers back on your terms.
Stop blasting the whole list. Filter by spend, gender and age, then send the promo to the segment that will actually act on it, and only to people who opted in.
Tuesday winback
ScheduledAudience snapshot
1,284
Frozen at schedule time, so it cannot drift before send
Excluded
317
opted out
Return visits on demand, not just organic.
Segment, do not spray
Everyone who spent $50 or more and has not been in for six weeks, 20% off Tuesday. That is a filter, not a mailing list.
Audience frozen at schedule time
The recipient list is snapshotted the moment you schedule. What you previewed is exactly what sends, with no drift between planning and delivery.
Opt-in only, opt-out respected
Nobody gets a campaign they did not agree to, and an opt-out is honoured everywhere immediately.
Demand you can turn on
A slow Tuesday becomes a segment and a send, instead of a hope that walk-ins show up.
No AI guessing. That is deliberate.
Serv is rule-based on purpose. A language model will happily invent a gluten-free option you do not serve, quote a price you changed last month, or promise a table you do not have. A keyword rule cannot. Every automatic reply is one you wrote and approved, and anything outside the rules goes to a human instead of being improvised.
- Deterministic replies, so the same question gets the same answer every time
- No invented menu items, prices or policies
- Unmatched messages escalate to staff rather than getting a guess
- Nothing you did not write ever reaches a guest
Architecture
Built like infrastructure, not a side project.
You are handing over the number your guests use. Here is what sits underneath it.
Two layers of tenant isolation
Postgres row-level security plus service-role filtering. One deployment serves many restaurants, and your data is fenced off at the database, not just in application code.
Real authentication
Supabase Auth with JWTs signed by asymmetric keys. Proper session handling, not a login screen bolted on at the end.
Scheduling decoupled from sending
Deciding it is time to send is SQL and cron. Actually sending is the API. Job infrastructure can be swapped without touching business logic.
Designed for channel expansion
The adapter pattern under the inbox means Instagram, Telegram or SMS are new adapters, not a rewrite.
Questions worth asking before you connect your number.
No. Serv connects to your existing number through the official Meta Cloud API, so your guests message the same place they always have.
No, and that is the point. Serv uses keyword rules with word-boundary matching in a priority order, first match wins. Replies are deterministic and written by you. Anything that does not match a rule is escalated to a human rather than answered by a guess.
The conversation moves to NEEDS_ATTENTION and appears in your team's queue. It is never silently ignored, and the bot never improvises a reply.
Yes. Switching a thread to HUMAN mode mutes the bot for that conversation entirely, so a guest never gets an automated reply mid-conversation with a person.
A scheduled job fires two hours after a visit is logged. The guest gets a short button flow, rating the food and then the atmosphere, and the outcome branches on the score.
Nothing stops a guest posting wherever they like, but Serv only asks for a public Google review when the rating clears your threshold. Below it, the feedback is captured internally and your staff is flagged while there is still time to fix it.
Campaigns are opt-in only and opt-outs are respected immediately. Audiences are filtered by spend, gender and age, and the recipient list is snapshotted when you schedule so it cannot drift before it sends.
Yes, at two levels: Postgres row-level security and service-role filtering in the application layer. Tenant isolation is enforced by the database itself, not only by code.
WhatsApp is what ships today. The inbox is built on a ChannelAdapter interface, so additional channels are new adapters rather than a rewrite of the core.
See it running on your own menu.
Twenty minutes with your actual questions, your feedback thresholds, and one campaign built live. No slide deck.
No credit card. No commitment.