Every menu already lives in more than one place: the board over the counter, the point-of-sale item list, whatever a delivery app shows, the sheet taped by the line the kitchen actually cooks from. These rarely say exactly the same thing at the same moment. A server explains the difference out loud; a data-driven channel has no equivalent instinct — it only knows what it's told, which means the accuracy of the whole conversation is bounded by the accuracy of whichever list it's reading from, not by how well the software itself performs.
The practical fix isn't picking the “right” software — it's picking one place every other list defers to. A restaurant that adds a topping only to the printed menu, never to the system a voice channel actually reads from, hasn't really added it anywhere a caller can order it.
§ MODIFIER GROUPS, EXPLAINED CONCRETELY
Almost every real ordering problem traces back to how modifier groups are set up. Two properties matter most: whether a caller has to choose at all (required, or optional), and whether they can pick one option or several (single-select, or multi-select). The second distinction that trips up more menus than it should is included versus extra — a group can be all included, all extra, or a mix where the first choice is free and anything past it costs more.
| Modifier group | Selection rule | Included vs. extra | Example |
|---|---|---|---|
| Size | Required, exactly one | Price changes by selection | 10", 12", 14" |
| Crust | Required, exactly one | Base included, one option costs more | Thin, hand-tossed, stuffed |
| Toppings | Optional, any number | First two included, each extra costs more | Pepperoni, mushroom, onion |
| Add cheese | Optional, one on/off | Always an added charge | Extra mozzarella |
| Dressing | Required, exactly one | Included regardless of choice | Ranch, vinaigrette, on the side |
Read that as a template, not a fixed answer — a taco counter's groups look nothing like a pizzeria's. What stays constant is the two questions worth asking of every group before it goes live: does the caller have to choose, and does choosing cost anything beyond the base price.
§ DECIDING WHAT HAPPENS WHEN SOMETHING RUNS OUT
Marking something unavailable — 86'ing, in restaurant-floor terms — usually forces a decision most restaurants have never written down: unavailable at what level? A missing ingredient rarely touches only one dish; it touches every item where it appears as a topping, a side, or an optional add-on. The honest range of responses is wider than a flat yes or no:
- Stop offering the item entirely until the ingredient is back.
- Keep offering it, but drop the one option that depends on the missing piece.
- Offer a specific substitute and ask the caller to confirm it before it's added.
- Take the request as written and flag it for a person to sort out before the kitchen sees it.
None is universally correct — a pizzeria out of one specialty topping might quietly drop it from a combo, while the same restaurant running out of its only gluten-free crust almost certainly needs a caller-facing confirmation, because silently substituting changes something the caller specifically chose for a reason. Whatever a restaurant decides, the version that damages trust fastest is a channel that keeps selling something that's actually gone, because nobody updated the one list it was reading from.
§ ONE INGREDIENT, SEVERAL MENU ITEMS
A restaurant runs out of fresh mozzarella midway through a shift — an ordinary kitchen event. Three items built with it need three different, correct outcomes:
| Menu item | How mozzarella is used | What should happen |
|---|---|---|
| Classic cheese pizza | The base cheese — the dish is built around it | Stop offering, or confirm a substitute |
| Turkey club sandwich | One optional add-on among several | Keep selling; drop just that add-on |
| Garden salad | One of four topping choices | Keep selling; narrow that one choice |
A system that only tracks availability at the level of whole menu items can't produce three different, correct answers from one shortage — it either takes down all three, turning a minor gap into an unnecessary loss of sales, or takes down none, letting the pizza keep selling as if nothing changed.
None of this depends on choosing any particular channel — see how Dohos reads a menu, or request access to see it against your own data.