The classic four-box model, briefly
Plot every dish on two axes: how often it sells, and how much gross profit it contributes per sale. Four boxes fall out.
| High margin | Low margin | |
|---|---|---|
| Sells often | Star — protect it, do not discount it | Plowhorse — popular and thin; raise price or cut cost |
| Sells rarely | Puzzle — worth selling; fix the presentation | Dog — remove it, unless it earns its place another way |
Two notes and then we can move on. Use gross profit in currency, not percentage margin — a dish with a thin percentage and a large absolute contribution is often the most valuable thing on the menu. And a Dog sometimes stays: the one vegan main, the children's dish, the thing the regulars would notice.
The limitation is in the axes. Both are derived from sales, so both are silent about the dishes that were never ordered. A Puzzle and a Dog look identical from the till, and the fixes are opposite.
The new axis: views, not just sales
A digital menu records something a printed one cannot: which items a guest opened. That is a record of consideration — attention that did not necessarily become an order.
It turns one ambiguous box into two clear diagnoses.
| Sells rarely, and… | What it means | Where the fix lives |
|---|---|---|
| is rarely viewed | Guests are not reaching it. Nothing about the dish has been judged. | Position, category name, menu length |
| is often viewed | Guests are reaching it, reading it, and choosing something else. | Description, price, photo, or the dish itself |
Those two rows call for opposite work. Rewriting the description of a dish nobody scrolls to is effort spent on a page that is not being read. Moving a dish that is already viewed heavily does nothing about the reason people are declining it.
This is the entire argument for doing menu engineering on a digital menu. Everything else in the discipline predates it and works fine on paper.
Reading the view-to-order gap
Take an item's share of menu opens and its share of orders in the same period. The interesting items are the ones where the two disagree sharply.
A dish opened by one guest in five and ordered by one in fifty has been looked at and turned down repeatedly. That is a specific, actionable finding, and there are only a handful of reasons for it:
- The price is above what the description justifies. Not too expensive — insufficiently explained for the money.
- The description does not say what arrives. Vague dishes lose to legible ones when a guest is deciding quickly.
- An ingredient is quietly disqualifying, and the guest found out on the item page rather than on the list.
- The photo undersells it, or there is a photo on the competing dish and not on this one.
- It is genuinely not wanted at this venue, at this price, by these guests.
The last possibility is real and worth holding on to. A view-to-order gap is a question, not a verdict — the honest reading of some gaps is that the dish should go.
Position on a scrolling menu is not position on a printed one
Menu engineering carries a body of received wisdom about eye paths: the golden triangle, the top-right sweet spot, the primacy of the first item in a list. Most of it comes from research on printed menus, usually two-page ones held at reading distance.
A phone menu does not work like that. It is a single narrow column, one or two items visible at a time, navigated by scrolling and by tapping into categories. There is no top-right corner. Carrying the printed findings across unexamined is the most common error in this area.
What does appear to survive the move — and is worth testing rather than assuming:
- First-in-list positions get disproportionate attention, because they are what a guest sees on arriving in a category.
- The last item before a category ends gets a smaller version of the same effect.
- Category order matters more than item order, because a guest who never opens a category has not seen any of it.
- Long categories bury their middles. Twelve items in one category means items five to nine are effectively invisible.
The practical consequence is that your first fix for a low-view dish is usually structural — a shorter category, a better category name, or a higher position — rather than editorial.
Descriptions, photos, and changing one at a time
You will find the claim that descriptive menu language lifts sales by around a quarter. It is repeated widely, traces back to a small number of academic studies on printed menus, and is not a number to plan against. The direction is well supported; the magnitude is not.
What holds up in practice is narrower and more useful. A description earns its place when it answers the question the guest actually has, which is usually one of three:
- What arrives on the plate. Components, and roughly how much.
- What it tastes like, in words a guest can imagine — heat, richness, acidity, texture.
- Why it costs what it costs. Provenance, method, or time, where those are genuinely the reason.
Photos are stronger than descriptions and more dangerous. They lift views reliably — an item with an image out-taps its neighbours almost regardless of the dish — which means a photo added to a low-view item has changed the measurement as well as the outcome. And a photo that oversells produces a disappointed guest, which costs more than the extra covers gained.
Hence the discipline: change one thing per item per period. If you rewrite the description, add a photo and move the item up two places in the same week, you have learned nothing except that something worked.
Testing a change without a POS integration
Proper A/B testing needs to split traffic and attribute orders, which needs an integration you do not have. What is available is a before-and-after comparison run carefully enough to be worth something.
- Fix the window. Four weeks before, four weeks after. Never compare the week either side of a change — you will be measuring the weather.
- Compare like periods. If the after-window contains a public holiday or a festival and the before-window does not, the comparison is void.
- Change one item, one attribute. Everything else on the menu stays still, including prices.
- Record both numbers for that item: view share and order share. A change that lifted views but not orders has moved attention without moving the decision, which is a different result and usually means the price or the description is the blocker.
- Check the neighbours. A lift that came entirely out of the dish next to it is cannibalisation, not growth — worth knowing before you repeat the trick.
- Write down what you changed, when, and what happened, in one line.
This is weaker evidence than a real test and it is not nothing. Run it monthly for a year and you have twelve recorded experiments and a menu that improved for reasons you can name.
A monthly review that takes an hour
The whole practice fits in one sitting per month, and fails when it becomes a dashboard people glance at daily.
- Export last month's sales by item from your POS, and last month's item views from the menu.
- Join them into one sheet: item, orders, gross profit per order, views.
- Sort by view share and mark every item in the top quarter that is in the bottom quarter by orders. That is your candidate list, usually three to six dishes.
- Sort by views ascending. Anything with almost no views is a position or category problem, not a dish problem — fix the structure first.
- Pick one item from each list. Two changes a month, no more.
- Read last month's line in your changelog and record whether it worked.
Step six is the one that makes the rest compound and the one that gets dropped first. A year of changes with no record is a menu nobody can explain.
Where this analysis stops being reliable
The limits are worth stating plainly, because the failure mode of menu engineering is over-confidence in thin data.
- Small venues do not generate enough events. Under a few hundred menu opens a month, item-level shares are noise and should not be acted on.
- Seasonal menus break the method. A dish that ran for six weeks cannot be compared with one that ran all year.
- One scan often serves a table, so views under-count consideration by a factor that changes with party size.
- Views cannot see the server. A dish the floor recommends will out-sell its view share, and that is a good thing being measured as an anomaly.
- Gross profit per dish is only as good as your costings. Stale ingredient costs will misclassify half the grid.
- Guests who ordered from a printed menu are invisible on the view side entirely.
None of these invalidate the exercise. They set its resolution: this is a method for finding two or three things a month worth looking at, not for optimising a menu to a decimal place. The decision is still yours, and the room still knows things the data does not.
The same menu data has a second job that has nothing to do with the dining room — see restaurant menu seo.