Ordering bots for food: modifiers, and the Friday night problem

Food ordering looks like the friendliest case for a conversational bot. People know what they want, the menu is finite, and the transaction is small. Two things make it harder than it looks, and both are specific to food rather than to conversation.

The first is that a menu with options is not a list, it is a combinatorial space, and customers navigate it in language rather than by selecting. The second is that the entire business happens in a few hours, during which the kitchen is the constraint and a bot that keeps taking orders is actively harmful.

What we'll cover

• A menu is not a list
• What customers actually type
• Modifiers, and the ones that are not on the menu
• Allergens, where being accommodating is unsafe
• Building it with CodeWords
• The Friday night problem
• Quoting a time you can keep
• Delivery areas and the edge of the map
• The order that reaches the kitchen
• Making it survive
• Limits worth knowing about
• What to model first
• Frequently asked questions

A menu is not a list

Model the menu as items and it will not survive contact with customers.

An item has a size, which changes the price and sometimes the available options. It has a base, which may itself have variants. It has included toppings, which can be removed, and additional ones, which can be added, and each addition has its own price that may depend on the size. Some combinations are not possible. Some are the same thing under two names.

That is a structure rather than a list, and a bot that treats it as a list will price things wrongly and accept combinations the kitchen cannot make.

The work is to write it down properly once: what varies, what depends on what, what is excluded, and what each change costs. Businesses usually discover their own menu is inconsistent while doing this, which is worth finding out.

What customers actually type

People do not order the way a menu is structured. Collect twenty real orders and you will see it immediately.

They order by remembered name rather than menu name. They say "the usual" and expect you to know. They order by describing it, "the one with the spicy sausage". They combine and negate in one breath: "two large, one without onions, one with extra cheese, and can you do half and half". They change their mind mid-sentence. They order for other people and relay preferences second-hand.

A bot handling this needs to map language onto the structure, and it needs to be honest when it cannot. The failure that costs money is confidently interpreting an ambiguous order, because the customer discovers it at the door.

Where something is ambiguous, ask about that one thing. Where an item does not exist, say so and offer the nearest, rather than silently substituting.

Modifiers, and the ones that are not on the menu

Customers request things your modifier list does not contain, constantly.

Well done. Light on the sauce. Cut into squares. Extra hot. Sauce on the side. No basil because someone does not like it. Some of these are trivial for the kitchen, some are impossible, and none is in a structured options field.

Two decisions. Which free-text notes are you willing to accept and pass through, and which must be refused or escalated. And how does a note reach the kitchen in a form somebody will actually read during service, because a note that appears in the wrong place on a ticket is a note that gets missed.

The safest default is to accept preparation preferences as notes, pass them through visibly, and escalate anything that changes what is being made or implies a dietary requirement.

Allergens, where being accommodating is unsafe

The one area where the instinct to please is dangerous, and where a bot must be deliberately unhelpful.

A bot must never confirm that a dish is free from an allergen. Recipes change, suppliers change, and a shared kitchen usually cannot guarantee the absence of anything. An automated reassurance here is a serious risk, and the honest answer is frequently that you cannot guarantee it.

What a bot should do is provide the allergen information you hold, say plainly that it cannot guarantee absence in a shared kitchen, and route any message mentioning an allergy or intolerance to a person before the order is accepted. The requirements differ depending on how food is sold, and the current position is set out in the FSA allergen guidance.

Treat any mention of an allergy as an escalation, every time, without the bot attempting a judgement. This is the rule to write down first.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the menu structure, what can be modified, the delivery area, and the rule that allergy mentions always reach a person.
3. Authorize the connections to your ordering or till system, your payment provider, and the channel customers use.
4. Describe the exceptions: an item unavailable, an address outside the area, a kitchen at capacity, anything mentioning an allergy.
5. Drive quoted times from a real kitchen state rather than a fixed number, since a promise made at eight o'clock on a Friday is the one that gets broken.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

The Friday night problem

Most of the week's orders arrive in a few hours, and during those hours the kitchen is the constraint rather than the ordering.

A bot that accepts orders at a constant rate while the kitchen falls behind is making things worse. It is converting a queue you could have managed into a set of promises you cannot keep, and the complaints arrive later when the food does.

So the ordering system needs to know something about kitchen load, even crudely. Orders accepted in the last period against what the kitchen can produce. When that gets tight, the honest responses are a longer quoted time, temporarily removing the slowest items, or pausing new orders, and all three are better than accepting everything.

The instinct is that refusing an order is lost revenue. A refused order is one unhappy customer; forty late deliveries are forty, plus the reviews.

Quoting a time you can keep

The number customers care about most, and the one most often invented.

A fixed estimate is wrong for most of the evening. It is too pessimistic at six and badly optimistic at eight, and the eight o'clock version is what generates complaints.

Base it on current load, widen it when the kitchen is busy, and give a range rather than a single time. Then, if it slips, say so before the customer notices. A message saying an order is running late, sent unprompted, changes the experience substantially. Silence followed by late food does not.

Never quote a time that depends on a driver being available unless you know one is.

Delivery areas and the edge of the map

A delivery boundary is a business rule with edge cases and customers live on the edges.

Check the address before taking the order, not after. Handle partial addresses, which is most of what people send. Be clear about minimum order values that vary by distance, and any charge that applies, before the customer has committed rather than at payment.

For addresses just outside the area, a flat refusal loses somebody who would happily collect. Offering collection instead converts a share of them and costs nothing.

The order that reaches the kitchen

Everything upstream is wasted if the ticket is unreadable during service.

Group by item rather than by the order the customer mentioned things. Put modifications directly against the item they belong to, never in a separate notes field at the bottom. Make anything unusual visually obvious. Include only what the kitchen needs, since the customer's phone number belongs on the dispatch side rather than in the middle of a ticket.

Test this during an actual busy service rather than in an empty kitchen. A format that reads well at three in the afternoon is not necessarily one that reads well at eight.

Making it survive

Keep the menu structure as the source, with an owner and a review date.

Escalate every allergy mention, without exception.

Drive quoted times from real load, not a constant.

Tell customers about delays before they ask.

Read twenty real orders monthly, especially the ones that went wrong.

Limits worth knowing about

A bot cannot add kitchen capacity, and taking more orders during peak makes the evening worse.

Ambiguous orders exist, and confident interpretation is more expensive than asking.

Allergen guarantees are not available in a shared kitchen, and no phrasing changes that.

Delivery estimates are predictions, so a range plus an honest update beats a precise number.

The ticket format decides accuracy, more than the conversation does.

What to model first

The menu, properly: sizes, bases, included and additional options, what each modification costs, what combinations are impossible, and which names mean the same thing. It is an afternoon's work, it usually exposes inconsistencies in your own pricing, and every downstream problem here is caused by having skipped it.

Two habits make the difference. Route every mention of an allergy to a person before accepting the order, since this is the one place where a helpful automated answer can do real harm. And drive the quoted time from what the kitchen is actually carrying, because a fixed estimate is a promise you break exactly when you are busiest.

Frequently asked questions

Why is a food menu harder to model than it looks?

Because it is a structure rather than a list. Size affects price and available options, included toppings can be removed, additions have prices that vary by size, some combinations are impossible, and some items have two names.

How do customers actually order?

By remembered names, by description, by combining and negating in one sentence, and by relaying other people's preferences. Collect twenty real orders and design against those rather than against the menu's structure.

What should a bot do with an ambiguous order?

Ask about the ambiguous part specifically. Confidently interpreting an unclear order is the failure that costs money, because the customer discovers it at the door.

How should special requests be handled?

Accept preparation preferences as notes passed through visibly to the kitchen, and escalate anything that changes what is being made or implies a dietary requirement.

Can a bot answer allergen questions?

It can provide the information you hold and must never confirm that a dish is free from an allergen. A shared kitchen usually cannot guarantee absence, and every mention of an allergy should reach a person before the order is accepted.

What happens at peak times?

The kitchen becomes the constraint. An ordering system that keeps accepting at a constant rate converts a manageable queue into promises you cannot keep, so it needs some awareness of load.

Is it better to refuse an order than take it?

Often yes during peak. One refused order is one unhappy customer; forty late deliveries are forty, plus the reviews.

How should delivery times be quoted?

As a range, based on current load rather than a fixed number, widened when busy, with an unprompted message if it slips. Never quote a time dependent on a driver you do not know is available.

What about addresses outside the delivery area?

Check before taking the order, handle partial addresses, and state distance-based minimums and charges before the customer commits. For addresses just outside, offering collection converts a share of them.

What makes a good kitchen ticket?

Grouped by item, modifications against the item they belong to rather than in a notes field, anything unusual visually obvious, and nothing the kitchen does not need. Test it during a real service.

Related reading

• Taking orders and keeping the record straight
• Keeping a price list true
• The cutoff on changes