Playbooks · 6 min read
Daily Specials, Dead Automations and the Table You Cannot Confirm
Look at a restaurant's grid and you are not looking at a portfolio. You are looking at a calendar that forgot to turn its pages.
Wednesday's thali. Last month's Ganesh Chaturthi menu. The winter brunch you ran for six weekends. A happy hour that ended in March. Every one of those posts is still there, still discoverable, still collecting comments — and every one of them was true on the day it went up and is a small lie now.
Automation makes that worse in a way nothing else does, because an automation attached to a dated post does not age with the post. It stays exactly as confident on day two hundred as it was on day one.
The refusal list — allergies, complaints — is a separate post and it is the one to build first. This one is about the two things that break next: content with a date in it, and the reservation you are not able to confirm.
Sort your posts into two piles before you build anything
There are only two kinds of restaurant post and they need completely different automations.
Evergreen
Perishable
The left pile is where automation earns its keep. Those templates are written once and stay true for years, they answer most of the volume, and they cost nothing.
The right pile is a temporary structure. It gets built with a demolition date already decided, and that date goes in the same list as taking down the A-frame board and rubbing out the chalk. Nobody forgets the chalkboard. Everybody forgets the automation, because the automation is not standing on the pavement embarrassing you.
Write specials so they cannot go stale
The sharper trick is to make the template survive the day it was written for.
"Brunch is on today, 12 to 4, walk-ins welcome" is correct for about six hours and wrong for the rest of its life. "Brunch runs on Sundays — the current menu is always in our bio link" is correct forever, and it is the same message from the reader's point of view.
The rule generalises. Point rather than state. Anything with a specific day, a specific price or a specific dish in the words is a sentence that will outlive the fact.
Prices deserve the same treatment. Menu prices move, suppliers move them, and a figure typed into a template is a figure your account keeps repeating months after the printed card changed. "Sending you the current menu" survives a revision.
The reservation problem, stated plainly
Now the harder one. A large share of a restaurant's DMs are some version of "table for 4 tonight at 8?"
Nothing here can answer that. There is no calendar integration, no table map, no booking system connection, and no way for an automated reply to know whether Saturday at 8:30 exists. Not a plan limit — it does not exist.
An automated "see you at 8" is a promise made by software about a room it has never seen. It gets discovered by a family standing in your doorway.
That failure has a specific shape and it is worse than most automation failures. A wrong answer to a menu question is a small annoyance. A confirmed table that is not a table is four people who dressed up, drove across town and are now standing in front of your host holding a screenshot of your own account.
So the reservation automation does one job and stops:
- Acknowledge immediately, and say what happens next. "Got it — sending this to the desk, someone will confirm shortly." Fast, honest, and it buys you the hours you actually need.
- Collect the four things in one message. Date, time, how many, and a name or a number. One message, not an interrogation across four turns you will not get.
- Never use the word confirmed. Not "booked", not "reserved", not "you're all set". The desk says those words. The template does not.
- Capture it to Leads, and give the export an owner. Leads leave as CSV. If nobody is named as the person who reads them, the automation is producing a list that nobody works.
- Let takeover do the rest. The second the desk replies by hand, automation is out of that thread permanently. No cheerful template landing under a manager's message.
The clock that costs you money
Comments stay answerable for seven days, counted per comment. A DM thread stays open for twenty-four hours from their last message, and only their next message restarts it. Official Graph API, both are the platform's rules rather than settings anyone can change.
For a restaurant the DM clock is the expensive one. Someone asks about Friday dinner at 10:40pm on Thursday. If the first human sees it on Saturday morning, the window has closed and so has the evening they were asking about. A free templated acknowledgement sent at 10:41pm is not a substitute for the desk. It is what keeps the desk's reply possible.
What it costs, and what it will not do
Templated replies are free and unlimited. A credit is spent only when the AI writes a new reply, one credit per reply. A restaurant built the way this post describes runs almost entirely on templates, because the whole point is that the wording is fixed. The free tier is 100 credits with no card and packs start at ₹499.
Set a rate budget before you post anything likely to travel. A cheese-pull reel behaves nothing like your usual grid, and an uncapped automation answering two thousand comments in an hour is how a good night starts looking like spam. The seven-day window means the queue drains long before it expires.
It cannot see your tables, take an order, take a payment, or message anyone who has not messaged you first. It does not do WhatsApp and it does not publish anything, so the dated post is still yours to make.
Build the refusal list, then the evergreen templates, then one dated automation with a switch-off date written down. How the comment-to-DM flow actually works is the mechanic underneath all of it, and what a booking automation can honestly say covers the desk side in more detail.
