Playbooks · 5 min read
WhatsApp for Bakeries: The Cake Order Is the Real Thread
A bakery sends two kinds of message and they are not close cousins. One is attached to a cake somebody has already paid an advance on. The other is a photograph of this morning's croissants sent to everyone whose number you have.
WhatsApp treats those two very differently, and most bakeries find that out in the wrong order.
The order thread does the work
A custom order is a small project. Someone messages about a birthday cake. You ask how many people, what flavour, eggless or not, when they need it. They send a Pinterest screenshot. You quote. They send an advance. Two days later they change the name on the top. On the morning of, you send a photo before it goes in the box.
That is eight or ten messages over four days, and almost all of it happens inside the twenty-four-hour customer service window that opens every time the customer writes to you. Inside that window you reply freely, in your own words, with photographs. You are not composing approved templates. You are talking.
This is the part of WhatsApp that actually suits a bakery, and it is also the part that needs the least technology. A person with the shop phone does it well.
The order thread is not something you automate. It is something you avoid dropping.
Where the WhatsApp Business Platform starts to matter is the edges of that thread — the messages you need to send when the customer has gone quiet and the window has closed. "Your cake is ready for pickup from 4pm." "We tried delivering at 11, nobody was home." Those are utility messages: they are about an order that exists, that the customer placed, on terms they already agreed.
To send one outside the window you need a pre-approved template. You write it, submit it to Meta, and it comes back approved or rejected. Then you fill in the variables — name, time, order number — and send.
The daily bake is a different animal
Now the other message. "Fresh sourdough out at 8, first come first served." "Christmas hampers open for booking."
There is no order behind that. It is a promotion, and WhatsApp categorises it as marketing. It needs an approved marketing template, and it needs the customer to have opted in to receiving that kind of message from you — separately from having bought a cake.
Bakeries get this wrong sympathetically. The daily bake feels like a service — regulars genuinely want to know when the ciabatta lands. But wanting it and having consented to it are different facts, and only one of them is recorded anywhere.
The app on your counter is not the API
Worth saying plainly, because the pricing conversation is confusing otherwise.
The free WhatsApp Business app — the one on the phone next to the till, with the catalogue and the quick replies and the away message — is not the Cloud API. The app is a phone app. It has broadcast lists, but a broadcast only reaches people who have saved your number. It has labels, quick replies, and an away message, and for a single-outlet bakery that is often the entire requirement.
The Cloud API is the developer platform. It needs a Meta Business account and business verification, and Meta charges per conversation, by category. What those rates are depends on the country and they change, so the number is not something to take from a blog post — the shape of the cost is what you plan around, not the figure.
- Count your real volume first. If you take four custom orders a week, the app and one person is the answer. The API earns its keep when the pickup notifications alone are a job.
- Write the templates before you build anything. Ready for pickup. Delivery attempted. Advance received. Three sentences each. If you cannot write them, you do not need them yet.
- Ask for consent where the customer is already saying yes. At the counter, on the order form, at checkout — with the two purposes separated. Order updates is one box. Offers and new bakes is another.
- Keep an opt-out that works. Someone who says STOP or "band karo" must actually stop receiving the promotional side, and the person handling the phone needs to know how to make that happen.
The question a bot must never answer
"Is this eggless?" "Kya isme nuts hain?" "Jain hai?"
These look like menu questions. They are safety questions, and an automated system should refuse them and fetch a human. Your ingredients change with your supplier. A cross-contamination risk lives in your kitchen on a particular morning, not in a product description written in March. A generated answer will sound confident either way, because sounding confident is the only thing it is good at.
Build the refusal before you build anything clever. It costs nothing and it is the only rule on this page with a consequence you cannot undo.
What we actually run
PostEngage answers Instagram comments and DMs, and that is the whole product today. If your bakery's discovery happens on Instagram — the cake reel that travels, the two hundred comments asking for price — the mechanics there are worth knowing, because they differ from WhatsApp in one useful way.
A comment stays answerable for seven days. A DM thread for twenty-four hours, restarted only when they message you again. Templated replies are free and unlimited; a credit is spent only when the AI writes something new. The free tier is 100 credits, no card, and packs start at ₹499. A bakery answering "price kya hai" three hundred times with the same template spends nothing.
If that is where your volume lives, start with the bakery playbook for Instagram, then the comment-to-DM flow. And if you are a food business worried about what an automation is allowed to say at all, the safety post is the honest version.
