You built a structured ordering flow. The customer thinks they are talking to a restaurant. They are not wrong, because it is a chat. Here is how to design for that.
Previous article
One rule decides what you can send, when, and what it costs. Most restaurants learn it from their first invoice. Here it is in plain English, including what changes on 1 October.
Next article
The phone rings at 8:40pm asking whether to refund a customer. What breaks while you are away is a map of everything that was never written down.
Somewhere in your ordering flow, a customer has just typed: make it less spicy.
Your system has no idea what to do with that. There is no button for it. It arrived between selecting the biryani and confirming the address, in the middle of a sequence designed to go in a straight line.
And here is the thing. The customer has not made a mistake.
They are in WhatsApp. This is the app where they talk to their mother, their landlord and their colleagues. Every other message they have ever sent in this app went to somebody who read it. Nothing about the window tells them that this particular conversation is a form.
You built a structured flow. They think they are talking to a restaurant.
They are not wrong.
A form makes no promise of understanding. It has boxes, and the boxes tell you exactly what is expected. Nobody types a paragraph into a dropdown.
A chat makes a very different promise. It implies that whatever you say will be read and considered, because that is what has happened in every other conversation the person has had in that app.
So the moment you put ordering inside a chat window, you have claimed conversational competence, whether or not you have it. The medium set that expectation, not your feature list, and you do not get to opt out of it.
Which is why the failure feels so much worse here than on a website. A dropdown that has no option for less spicy is a limitation. A chat that ignores less spicy is a restaurant that is not listening.
If you read the unrecognised messages from a live WhatsApp ordering deployment, they cluster fairly predictably.
Modifications. Less spicy. No onion. Extra gravy. No coriander. Make the roti well done.
Substitutions. Can I swap the rice for roti. Can the paneer come without the sauce.
Memory. Same as last time. The usual. What did I order on Friday.
Questions. Is the fish fresh today. Is there cashew in the korma. Is this Jain.
Timing. Can you make it for 8:30, we have people coming.
Changes after the fact. Cancel the raita. Add one more biryani.
Social messages. Thank you. Folded hands emoji. A thumbs up.
Voice notes.
And photographs, usually of a menu screenshot from somewhere else, or of the food they had last time.
Not one of those is an edge case. Together they are a substantial share of everything a real customer sends, and every single one of them arrives outside your flow.
There is an academic case study of a restaurant chatbot deployment, Rendezfood, that documented what users actually sent versus what the system was built to recognise.
One of the most common things people sent was thank you. It mapped to a category the designers had not created, and the study reports that this often produced highly inappropriate responses.
A restaurant chatbot that could not handle thank you.
That is not a technology failure. Nobody forgot how to program politeness. It is a design failure, and specifically a failure to sit down and write out what a human being says to a restaurant, as opposed to what a user does in a checkout funnel.
The same study noted something more encouraging: triggering the fallback did not necessarily wreck the conversation, as long as the fallback offered the person somewhere to go next.
Which is the whole design lesson in one line. Being misunderstood is survivable. Being stuck is not.
There is a difference between a form and a chat that operators consistently underestimate.
In a form, no response is normal. You fill a field, nothing happens, that is how forms work.
In a chat, no response is rejection.
Somebody who types no onion please and receives nothing back does not conclude that the system lacks that feature. They conclude they were ignored, and more importantly they conclude the kitchen did not get it either. Which means they now expect onion, and they are already slightly annoyed before the food has been cooked.
An acknowledgement that cannot act is still worth sending. Got it, I have passed that to the kitchen is enormously better than nothing, and it costs you nothing inside the service window.
Here is where most deployments get the priority backwards.
Modifications get treated as noise. Something to be handled, deflected, or narrowed down with a menu of buttons until the customer gives up and picks one.
But make it less spicy is not noise. It is a customer telling you precisely how to turn them into a regular. It is preference data, offered voluntarily, in their own words, at the exact moment it is actionable.
On an aggregator, that request goes into a free text box that the kitchen may or may not read, and you never see it again. In a chat, it is a message a person can act on and a system can remember.
The goal is not to suppress conversational input. It is to catch it.
The practical way to design this is to sort every possible message into one of three groups, and treat each group completely differently.
Things that must be exact. Items, quantities, price, address, payment. These should be structured, tapped rather than typed, and never left to interpretation. Ambiguity here becomes a wrong order and a refund. Nobody should be typing their order in prose if a button will do.
Things that need a human. Modifications, ingredient questions, timing requests, complaints, anything unusual. These are lower volume and higher value, and they require judgement rather than parsing. The right answer is a person, not a better model.
Things that must be remembered. Same as last time is not a language problem. It is an order history problem. No amount of natural language understanding helps if the system cannot look up what they ordered on Friday.
Most bad deployments fail because they try to solve all three with the same mechanism.
This is the design principle worth building around, and it is a lower bar than it sounds, which is exactly why it works.
You do not need a system that comprehends every message. You need a system where no message results in a dead end.
Analysis of conversational commerce failures keeps landing on the same conclusion: customers get trapped in loops because the bot has no reliable path to a human once the interaction moves past its safe limits. The failure is almost never that the bot did not understand. It is that not understanding had nowhere to go.
So the escape hatch matters more than the comprehension. A visible, always available route to a real person, on every screen, at every step, answered by somebody who can see the thread.
There is a related boundary worth drawing, which is about authority rather than understanding. A system that can accept cancel the raita after payment has been taken is making a commercial decision. Conversational systems get into trouble when they act beyond what they were authorised to do, not when they misread a sentence. Decide in advance what the flow is allowed to change on its own, and route everything else to a person.
In India this is not an edge case and it is worth planning for deliberately.
Voice notes are mainstream. They are how older customers communicate, how people order while driving, and how a great many people who are not comfortable typing in English get things done. A customer sending a thirty second voice note describing their order is behaving completely normally in this country.
Most ordering deployments have no answer for this at all. The minimum acceptable answer is not transcription or clever handling. It is that the voice note reaches a human being who listens to it and replies, rather than vanishing into a system that only reads text.
The objection to all of this is usually staffing. If a person has to handle the exceptions, does that not defeat the point of automating anything?
It does not, because the distribution is heavily skewed. Most orders are entirely ordinary: the customer taps items, confirms an address, pays, and never types a sentence. The off script messages are a minority of interactions, and they cluster around the same handful of requests.
That is a manageable amount of human attention. It is also the highest value attention in the whole operation, because those are the customers expressing a preference, asking a question, or telling you something is wrong. Those are the interactions that decide whether somebody comes back.
Automating the ordinary in order to free a person for the unusual is the right shape. Automating everything and hoping the unusual goes away is not.
Structure what must be exact, and leave what is human to humans. Items and payment through buttons. Modifications through a person.
Acknowledge everything, even when you cannot act on it. Silence in a chat reads as being ignored.
Capture free text verbatim and attach it to the ticket rather than trying to parse it into a category. A modification recorded word for word and shown to the kitchen beats a parsed one that got it slightly wrong.
Put a visible route to a person on every step. One tap, always there, no hunting.
Route voice notes to a human rather than ignoring them.
Set boundaries on what the flow can change by itself, particularly after payment.
And read your unrecognised messages every week. That log is not a list of errors. It is a product roadmap written by your customers, in their own words, telling you exactly what they expected your restaurant to be able to do.
Every ordering system has a moment where the customer steps outside the flow. Website, app, kiosk, chat, all of them.
The difference on WhatsApp is that stepping outside the flow does not feel like stepping outside anything. It feels like talking, because the customer is in the app where talking is the entire point, and nothing on that screen told them otherwise.
You can treat that as a problem to be trained out of people with more buttons and firmer prompts.
Or you can treat it as what it actually is, which is a customer telling your restaurant something useful, in a place where somebody can hear it.
Make it less spicy is not an unhandled input.
It is a returning customer, if anybody is listening.
Take orders where people already talk. Menuthere turns your WhatsApp number into an ordering channel, with the structured part structured and a real conversation still available underneath it.
Sources: Rendezfood conversational restaurant design case study (intent mismatch, fallback behaviour, unhandled gratitude), CMSWire 2026 (conversational commerce governance, authority boundaries, human handoff), Chatbot.com and Jotform 2026 (fallback logic, escalation, bot loops).
WhatsApp ordering
Most operators know this number. It gets quoted in every WhatsApp group in the industry. What gets discussed far less is the second cost, the one that never appears on the invoice.
WhatsApp ordering
The office group picks lunch in a WhatsApp thread, then somebody exits to place the order from memory. Everything lost in that gap was your revenue.