atace
← All posts

Menu Variants, Extras & Smart Recommendations

Menu variants, extras and product recommendations, set up correctly, raise average check size without extra staff effort. Here's how to structure the logic.

6 min read

Why menu variants and extras change your average check

Menu variants, extras and recommendations, set up correctly, lift average check size without asking staff to sell any harder. On a printed menu these three elements usually either don't exist or sit in small print on a side page — the guest never notices, and the waiter doesn't have time to walk through them at every table. The result is lost upsell revenue that the menu itself is hiding.

The cost isn't only missed revenue. When variants and extras aren't clearly defined, orders become ambiguous — "medium" or "medium-rare," extra cheese or not — and these details get lost in verbal communication before they reach the kitchen. This piece covers how to structure variants, extras and recommendations, which one should be mandatory versus optional, and how moving this logic into a digital menu actually moves the average check.

Mandatory variants vs. optional extras: not the same thing

The most commonly skipped detail in menu design is that variants and extras follow different rules. A variant is a mandatory single choice that defines the item itself — doneness for a steak, milk type for a coffee. The order can't be completed without it, because without that choice the kitchen doesn't know how to prepare the dish.

An extra, by contrast, is optional and can be multi-selected — extra cheese, extra sauce, a larger portion. Skipping an extra still leaves a valid order, but every extra that is selected has to flow into the total automatically at its own price. Mixing the two in one list — showing doneness as if it were an optional extra, for instance — confuses the guest and sends incomplete information to the kitchen. Defining mandatory and optional choices separately, and blocking an order with a missing mandatory choice from being submitted at all, removes this confusion at the source.

What changes moving from a printed menu to a digital ordering flow

On a printed menu, variant and extra information usually sits on a separate page in small type; guests skip it and waiters don't have time to explain it. On a digital menu, the same information sits right on the product card at the moment of choice — selecting "Grilled Burger" immediately opens the doneness option below it, with the extras list showing its price difference inline.

The practical effect is that the choice becomes visible and tappable instead of dependent on memory. In a verbal order, a waiter can easily forget to ask about extra cheese; on a QR menu, that option is always on screen and the guest decides at their own pace. App-Rest's QR menu module defines these two layers — the mandatory single choice and the optional multi-choice — separately; each option's price difference is applied automatically, and an order with a missing mandatory choice can't be sent to the kitchen.

"Goes well with" recommendations: real order history, not a fixed catalogue

Beyond variants and extras, the third lever on check size is cross-item recommendation. The classic approach is for whoever built the menu to guess a fixed pairing — "this goes with that" — but that guess rarely matches what the restaurant actually sells. One branch might sell far more ayran than fries alongside a burger; a fixed catalogue pairing can't capture that difference.

A data-driven recommendation surfaces whichever items have actually been ordered most often together with the one just added to the cart. Because it's generated from the restaurant's own order history, it shifts naturally by branch, season and guest profile — cold drinks might lead in summer, soup in winter — with nobody updating a rule by hand. A guest who has already decided to order sees a relevant, low-cost add-on ("add an ayran?") with no sales pressure attached, and that's what lifts average check size organically.

Pricing and stock behind variants and extras

The part of the system guests never see, but that matters most, is where the price is calculated. A price sent from the client side should never be trusted directly — the server has to compute the total itself from the item's base price plus every selected extra's defined price difference. Otherwise a manipulated client request can quietly break the restaurant's pricing integrity.

The same logic applies to stock. If an extra — extra avocado, say — has its own recipe and ingredient cost, selecting it should deduct that ingredient from stock. If stock runs out, that extra option should automatically become unselectable, so the kitchen never receives an order for an ingredient it doesn't have, and the guest never orders something that turns out to be unavailable.

What changes for staff: fewer errors, less time lost

When variants and extras are clearly defined on the menu, the order that reaches the kitchen is clearer too. Details that used to depend on a waiter relaying them verbally — doneness, extra sauce, a gluten-free request — now sit in writing on the check and land directly on the kitchen screen. That cuts down on dishes coming back and removes the need for a waiter to circle back to a table mid-rush wondering "did I forget something."

The time savings show up most clearly during a busy dinner service: the guest makes their own selections at their own pace, and the waiter spends less time collecting choices table by table and more time on service itself. We go deeper on how fewer order errors change day-to-day operations in our related piece on reducing order mistakes.

Measuring it: which report actually tells you it's working

The only way to know whether variants, extras and recommendations are actually working is to measure it — "it feels like it's up" isn't enough. The core metric to track is average check size, comparing the period before the recommendation system went live against the period after. Beyond that, reporting which extra and variant combinations sell the most (and which get ignored) shows which recommendations are actually landing.

That data turns the menu from a static document into something you keep refining — a rarely chosen extra can be dropped, and two items that are frequently bought together can be offered directly as a combo. Having that report readable straight from the dashboard, with no manual export to a spreadsheet, is what turns this into a weekly habit rather than a one-off review.

The takeaway: a small menu detail, a measurable revenue line

Variants, extras and recommendations aren't a single dramatic feature — but set up correctly, they're one of the few tools that lift check size organically, without adding pressure on staff or guests. Keeping mandatory and optional choices clearly separate, computing price and stock server-side, generating recommendations from real sales data, and measuring the result regularly — these four steps turn the menu from a passive list into an active sales tool.

If you'd like to set up variants, extras and recommendations on your restaurant's menu, take a look at the App-Rest product page, or reach out with questions about the menu and QR ordering modules.