Off-menu: the requests an agent must never improvise on
In short
A request is off-menu only when the catalog cannot price it and no standing kitchen rule covers it. Two other things get mistaken for it: a modifier that exists and the agent failed to find, and a change the catalog could express but the kitchen has never approved. Only the genuinely novel request should reach a person by default.
Key takeaways
- 3 things sound identical on a call: a missed modifier, an unapproved change, and a genuinely novel request.
- Escalating a missed modifier hides a retrieval bug behind a person, and the bug gets worse while nobody sees it.
- An unapproved change is a decision the operator owes the catalog once, not a decision the agent makes per call.
- Only the novel request should reach a person by default, and it should arrive with the order already built.
- Most restaurant catalogs express what an item is and not what the kitchen will do. That missing field is the whole problem.
A request is off-menu when the catalog cannot price it and no standing rule tells the kitchen whether to make it. That is a narrow definition on purpose. Two other things get filed under the label and neither belongs: a modifier that exists on the item and the agent failed to retrieve, and a change the catalog could express but the kitchen never agreed to.
The distinction matters because the 3 have different fixes. One is a search bug, one is a written policy the operator owes the system, and only the third is a call for a person. Treat all 3 as escalations and you get a phone line that hands off constantly while retrieval quietly degrades.
Three requests that sound identical on the phone
| Class | What the guest says | What the catalog can do | Default handling |
|---|---|---|---|
| In-catalog, not found | 'No onions on the second one' | The modifier exists on that item and is orderable now | Retrieve and apply. Escalating this masks a search bug |
| Expressible, not approved | 'Chilli oil from the noodles, on the wings' | Both parts exist; no priced pairing, no kitchen rule | Decide once, in writing, per item — not per call |
| Genuinely novel | 'Can you make the curry without dairy?' | Nothing prices it and no rule covers it | Hand to a person, keeping the order already built |
| Blocked by design | 'Can I have the chicken pink in the middle?' | The item carries a hard block on that change | Decline in 1 sentence, offer the nearest orderable thing |
| Off tonight | 'A portion of the special' | The item exists but is 86'd or outside its daypart | Say it is off and offer the substitute the catalog names |
The first row costs most, because it is invisible. A modifier the agent could not find looks exactly like a request the kitchen cannot make, and both end in a handoff. If unfound modifiers are the real problem, diagnose them as three modifiers in one breath and only two reaching the ticket. A rise at 19:00 that is absent at 15:00 is a noise problem: accurate in the afternoon, useless at seven.
The signals that make the call machine-decidable
An agent can only classify a request against what the catalog exposes. Four signals do most of the work, and most menu data models carry only the first two.
- Approved substitution sets. Which options may replace which, per item — not a global ingredient list. A catalog that cannot answer 'fries for salad' forces a guess.
- Availability now. 86 state and daypart, read at the moment of the call. An item that went off 4 minutes ago is a different answer.
- A free-text policy per item or category. Whether kitchen notes are honoured, ignored or blocked here, and what the agent may promise about them.
- A hard-block list. Changes nobody may order at any price — undercooking, allergen-free claims the kitchen cannot stand behind, portion changes that break recipe cost.
A note that is honoured also has to survive the journey. What the guest hears repeated is not necessarily what the kitchen reads, because an order becomes several documents with different field limits — see one order, three documents. A policy saying notes are honoured, on a path that truncates them, is worse than one saying they are not.
Handing over without losing the order
- Freeze, do not discard. Confirmed lines are still good. An agent that restarts the order on escalation turns a 30-second interruption into a 3-minute call.
- Name the blocker in 1 sentence. 'I can't put the chilli oil on the wings' tells the guest what to ask for. 'Let me get someone' makes them repeat the whole order.
- Offer the nearest orderable thing first. Many of these resolve into something the catalog already prices, and that costs nobody a handset.
- Only then offer a person, and say what happens next — a transfer now, or a call back in a stated window. That step fails in its own ways: the handoff that fires correctly while the call still dies.
- Pass the built order with the call. Whoever picks up should see the lines, the blocker and the transcript fragment, not an empty screen.
Where the line should sit
Set the boundary at pricing, not at unusualness. If the catalog can produce a priced line the POS will accept and the item's policy permits the change, the agent may take it. If it cannot, no prompt instruction makes it safe: the agent would promise something the kitchen never agreed to and the till cannot charge for. Intent has to be settled first — what a restaurant phone line is actually asked for.
Off-menu is not a property of the request. It is a property of your catalog on the day the call arrives.
The practical work is usually catalog work, not agent work: writing down decisions the kitchen has made informally for years so software can read them. That modelling sits at the front of voice and phone ordering and runs through software for restaurants and food service. Where the catalog has to be rebuilt to carry it, that is MVP and product build work.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
Should a voice ordering agent ever refuse a request outright?
Yes, for anything on the hard-block list — undercooking, allergen-free claims the kitchen cannot stand behind, or portion changes that break recipe cost. Refusal is safer than escalation there, because handing it to a busy person under pressure is how an unsafe promise gets made. Every other class either resolves in the catalog or goes to a person with the order intact.
How do we tell a missed modifier from a genuine off-menu request?
Query the catalog for the option under that specific item, by name and by alias. If it exists and is orderable, the agent had a retrieval failure and the request was never off-menu. Sampling 20 escalations a week and running that query on each is enough to see the split, and the retrieval share is usually larger than the team expects.
Can the agent promise a change the kitchen has not approved if the guest insists?
No. An unapproved change is an operator decision, not a per-call judgement, and an agent that concedes under pressure produces tickets the kitchen argues with at the pass. Name the blocker, offer the nearest orderable alternative, hand over. If the same request keeps arriving, that is the signal to add it to the catalog as a priced option.
Does allowing free-text notes solve the off-menu problem?
No, it moves it. A free-text note helps only if the kitchen has agreed to read notes on that item and every document in the chain carries the text intact. Otherwise the guest hears a promise, the note is truncated downstream, and the failure surfaces at collection rather than on the call.
- voice ordering
- menu modelling
- escalation
- special requests
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- Read-back: the moment a spoken order becomes a kitchen ticketRead-back is the commit boundary of a phone order — the last moment a wrong item is still free to fix. Everything the kitchen will act on differently has to be spoken before anything is written.definition
- Three modifiers in one breath and only two reach the ticketThe recording contains three customisations and the printed chit carries two. Which one goes missing tells you which layer dropped it — and transcription is the least likely answer.diagnostic
- What restaurant callers actually want before anyone takes an orderA restaurant phone line receives five different intents, and only one of them is an order. Each ends in a different system, so a single ordering script mis-serves four out of five callers.definition
Related across the site
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation