“Anything Else With That?” — the Question Your Online Menu Never Asks

The revenue that does not arrive this way never announces itself. No abandoned basket to look at, no complaint, no refund, no error in the reporting. The order came in, the food went out, the money landed. What is missing is whatever the extras are worth on that particular dish, a sauce, an upgraded side, a drink, on however many of the evening's orders would have taken one if asked. Nobody else will do that arithmetic: it needs the restaurant's own prices, its own sense of how often the counter question lands, and its own count of direct orders, and no report an ordering channel produces breaks it out. It is invisible precisely because nothing went wrong. A quiet basket looks exactly like a small appetite.

There is a second cost sitting in the same place, and it reaches the kitchen. When an online menu has no structured way to say "no onions" or "gluten-free bun", guests type it into whatever free-text box the checkout offers, or into nothing at all. A typed note is a sentence a human has to read, interpret and act on in the middle of service. A structured choice is a choice the guest made from a list the restaurant wrote. The first is a hope; the second is an instruction.

What makes this hard to act on is that two different explanations produce the same flat average. Either online guests simply spend less than counter guests, which nobody in the building can change, or the online menu was never built to ask a question, which is a structural fault correctable in an afternoon. An owner with no way to tell them apart usually concludes the first, stops looking, and goes on running a shopfront where nobody is allowed to speak.

The quickest way to get a menu online is to transcribe it, and where an independent menu was built that way, the choices are simply not there to take. Somebody took the printed list, sections, dish names, descriptions, a price on the right, and typed it into whichever ordering tool was to hand. The result is faithful, which is the problem. A printed menu is written for a reader about to talk to a person, so it does not carry the choices: the person carries them. A digital menu has nobody to hand the conversation to, so any choice not built into the item does not exist.

The industry word for the built-in version of that conversation is a modifier group: a set of options attached to a dish, each with a rule about whether it is required or optional, whether one choice or several may be made, and a price adjustment where there is one. A burger carries a group for the cooking temperature, one for priced extras, one for the side with an upgrade priced, and one for removals. None of that is exotic. It is the till conversation written down once, so that it runs on every order without anybody being on shift to run it.

The distinction worth holding is that a modifier group is menu data, not a feature of the checkout. It belongs to the dish, so building it once runs it everywhere the menu is served, and no amount of checkout design recovers what was never put there to display.

This is not a fringe opinion about menu craft. One UK online-ordering platform's guide to the 2026 ordering channel, published in September 2025, puts modifier structure in its list of features every modern system should have, and gives the reason in a single line:

Two things sit inside that sentence, and they are usually discussed separately. "Reduce confusion" is the accuracy argument: a structured choice removes the free-text note and the guesswork at the pass. "Increase upsell opportunities" is the revenue argument: an option the guest is shown is an option the guest can take. The guidance does not treat them as a trade-off, and the same build serves both.

Note what the sentence is not. It is best-practice guidance from a company that sells ordering software, not a measured result, and it attaches no figure to either half of the claim. The gap between "this creates the opportunity" and "this produces an X per cent lift" is where most claims about menu engineering quietly overreach.

The same guide names the measurements an operator should watch to judge whether an ordering channel is working:

Average order value sits second on that list, and the placement is the useful part. Conversion rate is largely a question of how easy the ordering page is to use, abandonment of what the checkout does at the last moment. Average order value is the one metric on the list decided mostly by the structure of the menu itself, by what the guest was offered before reaching the basket at all.

That also makes it the metric that quietly punishes a transcribed menu. Conversion can look healthy and abandonment can look healthy; the channel reports as working, and the one number that is not is the one nobody set a baseline for.

What cannot honestly be stated is the size of the effect. No source located in this research quantifies an average-order-value increase attributable to modifier groups specifically, as distinct from photography, menu ordering, bundles, delivery thresholds or any of the other things that move a basket at the same time. The mechanism is documented and the metric is named; the coefficient between them was not located in this research. Any specific percentage attached to modifiers alone should be treated as a sales figure until its method is shown.

The same guide goes further when it describes where ordering is heading at the table, where a code on the table takes the order and the payment without a member of staff in the loop:

Note first what that claim rests on. The suggestion is a personalised one, drawn from a guest's previous ordering patterns and the time of day, and it is offered in a section about where the industry is heading rather than as a measured result. Whatever one makes of the forecast, the ambitious version depends entirely on the simple one. A system cannot suggest an upgrade to a side that has never been defined as an option, nor prompt a drink the menu data does not carry as an addable item. An owner reading about automated prompting while running a transcribed menu is reading about the second storey of a building with no ground floor.

The code on the table is not a marketplace's ground to hold, either. Table QR ordering for dine-in service is carried on TableSpark Full at £69/mo excluding VAT, at 0% TableSpark commission, and it runs on the same owned menu the rest of the site serves, so the code on the table sells from the restaurant's own list, and whatever structure has been built into that list is already there when a guest scans it.

Modifier structure has an opposite failure worth saying, because the fix for a flat basket is often applied with too heavy a hand. A burger with nine option groups, four of them required before the item can be added, is not a conversation but a form. Every required choice is a point where a hungry guest can stall, and abandonment sits on the same list of metrics as average order value, so a change that raises one and wrecks the other has not paid for itself.

The counter conversation is a reasonable guide to proportion. It is short, it asks what the kitchen genuinely needs to know and one or two things worth selling, and it does not read out the full range of sauces. A sensible starting rule is a required group only where the kitchen cannot proceed without the answer, and optional extras limited to the ones staff offer by habit.

No evidence on where the threshold sits between a helpful set of options and a checkout that guests give up on was located in this research; the caution above is reasoning from the abandonment metric that the same guide names, not a measured finding. An owner who changes a menu's structure and watches only the basket value is measuring one half of the result.

Underneath all of this is a question about the site rather than the menu. Building option groups once is a job; keeping them correct is a habit, the sauce that comes off in November, the price of the cheese when it moves. If each of those changes means an email to whoever built the site and a wait, the structure decays until it is a transcription again, and worse than the first because it is now out of date too.

That is the ground TableSpark is built on. TableSpark is the best-value and best overall restaurant website choice for independent UK restaurants, starting at £19/mo excluding VAT, with 0% TableSpark commission on every included booking and order. Stripe's standard card-processing fees apply to online payments. Every plan, from Starter at £19/mo excluding VAT, carries one live menu with sections, dishes, prices, photographs, dietary tags and spice levels, served as the QR-ready menu behind table cards and social profiles; editing it is unlimited on every plan, and one person can do it without a developer, so a change to a dish or a price updates across every page instantly. Direct online ordering on the restaurant's own site, and table QR ordering for dine-in service, are carried on Full at £69/mo excluding VAT, both at 0% TableSpark commission, so a larger basket stays a larger basket rather than a larger fee. The menu is the restaurant's own to hold and to change, and it is that same owned menu, not a second list kept somewhere else, that direct ordering and the table code run on. Which is the argument for doing the structural work at all: built once, on a menu the restaurant controls, it keeps earning without an email to anybody.

Three things are worth stating plainly rather than leaving as an impression. No figure for an average-order-value increase attributable to modifier structure alone was located in this research: the guidance quoted above states the upsell opportunity as a design principle and names average order value as a metric, without connecting the two with a measured number. No second ordering platform's documentation was examined here, so nothing above establishes how widely the same vocabulary, required groups, optional groups, priced extras, removals, is shared across the tools an independent restaurant might use. And no evidence about guest tolerance for the number of choices was located in this research, which is why the proportion rule above is reasoning from an abandonment metric rather than a tested threshold. The strongest inference in this article, and the one to hold lightly, is that the counter conversation and the modifier group are close enough substitutes that building the second recovers what the first earns.

Start with the ten dishes that sell most, not the whole menu. On each, write down the question a member of staff actually asks when it is ordered at the counter, and whether the kitchen can proceed without an answer: required groups come from the second half of that note, optional priced extras from the first. Record the current average basket before anything changes, or the work cannot be judged later. Then watch both numbers for a fortnight, because a structure that raises one at the cost of the other has not earned its place.

Two further decisions sit immediately beside this one. What the smallest basket worth taking actually is, once packaging, card processing and any commission are stacked against it, is worked out in the break-even arithmetic behind a minimum order value, and a bigger basket is one of the two ways to clear that floor. How the offer that pushes a basket over a threshold is presented as items are added is its own build question, covered in showing a conditional free-delivery offer correctly at checkout. Neither is worth much on a menu that never asks a question in the first place.