Menu engineering on POS data: stop guessing which dish actually pays
The most popular dish on the menu is not always the one that truly funds the till. It often drives revenue and kitchen workload while leaving a thin margin on each portion. Menu engineering on POS data separates the two: how many units you sell and how many zloty you keep from one portion, without guessing and without confusing food cost percentage with whether the item really earns money.
In short: Take about 30 days of POS sales. For each item, calculate popularity and margin per dish in PLN (price minus portion cost from the recipe). Plot that on a simple 2×2 matrix. Only then decide: promote, fix cost or price, improve exposure, or retire. Food cost percentage is only a step toward portion cost, not an axis of this matrix. Rules for suggesting add-ons in orders make sense only after the matrix, not the other way around.
What menu engineering is and what it is not
Menu engineering is a systematic analysis of the menu on two axes: how many units you sell and how many zloty you keep from one portion after subtracting ingredient cost. The goal is simple: know which items to feature, which need a price or recipe correction, and which only take up inventory space and guest attention.
It is not:
- menu layout psychology alone (though layout can support decisions later),
- automatic “AI optimization” that rebuilds the menu by itself,
- a substitute for food cost control: food cost supplies portion cost, but it does not replace the popularity × margin-per-dish matrix.
Without sales data and an up-to-date portion cost, the matrix is a pretty chart on false numbers.
Popularity and margin per dish: formulas that must add up
Margin per dish in PLN
Margin per dish (sometimes called contribution margin on the dish) is simply:
margin per dish (PLN) = item selling price − portion cost (ingredients)
Illustrative example (not a typical restaurant result): burger 42 PLN, portion cost 15 PLN → margin per dish = 27 PLN. Food cost for that item is 15/42 ≈ 36%. Useful for controlling ingredient costs, but not as a menu engineering matrix axis.
Why zloty, not percentage? Take two dishes. Dish A: price 28 PLN, margin 18 PLN. Dish B: price 68 PLN, margin 22 PLN with a higher food cost percentage. Percentage may suggest A is “healthier.” At the till, B leaves more money from every portion. A matrix based on food cost % easily promotes cheap, low-margin hits at the expense of items that actually build the venue’s result.
Take portion cost from the recipe and current supplier prices. How to organize food cost and recipes: in the article on food cost from POS and in the inventory and recipes module (scope depends on plan).
Popularity
Work within one category (for example mains). Do not dump drinks and mains into one basket, or the result will be misleading.
expected share = 100% / number of items in the category
relative popularity = (item unit sales / category unit sales) / expected share
High / low popularity threshold: teams often use a line around the category average, or about 70% of expected share (so a large category does not doom half the items from the start). More important than a magic constant is one fixed rule for the whole audit, then the same rule on the next cycle.
Profitability axis: average margin per dish in PLN in the same category (or average weighted by portions sold). Above average = high margin; below = low margin.
The 2×2 matrix: four quadrants
| High margin per dish (PLN) | Low margin per dish (PLN) | |
|---|---|---|
| High popularity | Stars | Plowhorses |
| Low popularity | Puzzles | Dogs |
- Stars: sell well and leave a solid margin on the portion. The foundation of the result.
- Plowhorses: guests love them, the kitchen works hard, and money per portion is thin. The classic trap of “hit = success.”
- Puzzles: high margin, low sales. Potential hidden behind weak menu exposure, description, or missing server recommendations.
- Dogs: low sales and low margin. They block menu space, shelf space, and guest attention.
Industry naming varies (for example “cash cows,” “anchors”). The meaning of the quadrants stays the same: popularity × earnings in PLN per unit.
What to do with each quadrant
Stars
Do not break the recipe “to save money” if guests buy the quality. Protect ingredient availability, exposure on the menu, QR menu, or specials board, and consistent portion weights across shifts. These are the items that should always be ready in team recommendations.
Plowhorses
Do not delete a bestseller immediately. Look instead for a small price tweak, a cheaper or better-negotiated ingredient from the supplier, tighter control of add-on portions, or simplifying a garnish that ends up in the bin anyway. Goal: raise margin per dish without killing demand. After the change, measure sales and margin again. Do not assume success from a price hike alone.
Puzzles
Before you retire them: better description, photo, menu placement, server recommendation, or a test of suggesting an add-on or combo around the item (if you set such rules in the system). Often the problem is not taste but that the guest simply does not see the dish.
Dogs
Default: retire or rebuild deeply (new recipe, new price, new exposure). Exceptions: a seasonal item out of season, an image dish with a clearly counted marketing cost, or a contract or franchise requirement. “Uncle likes it” sentiment is not a matrix axis.
What POS data you need: at least 30 days
A shorter window easily skews the result. One banquet, an oven outage, or a weekend promo can distort the ranking. A longer window can blur the effect of the latest supplier price hike. For a first audit, about 30 days of representative sales is a sensible start. Then repeat the cycle after a meaningful menu or ingredient-cost change.
Minimum data:
- unit sales per item (sales ranking),
- selling price (account for real variants and discounts if they break margin per dish),
- portion cost from the recipe and current purchase prices,
- split into categories (for example mains separately, sides separately),
- context: promotions, season, stockouts in the period.
In OrderNow reports and analytics you get, among other things, average check, product ranking, and sales structure by category. Basic sales reports are on the Start plan; a fuller analytics pack, recipe-based food cost, peak-hour heatmap, and export are on Pro and Enterprise plans (details on pricing).
If recipes in the system have been sitting for a year, fix them first. A matrix on stale portion cost only legitimizes bad decisions.
From matrix to average check: without magic percentages
The matrix tells you what is worth selling more often. Average check rises only when guests choose Stars and Puzzles more often or add a sensible side or combo, not when someone promises “plus X percent to the check” without a source.
Illustrative example (working assumptions, not a case study of a specific venue):
| Item | Price | Portion cost | Margin per dish | Category share | Quadrant |
|---|---|---|---|---|---|
| Salmon bowl | 49 PLN | 18 PLN | 31 PLN | 4% | Puzzle |
| Classic burger | 39 PLN | 16 PLN | 23 PLN | 18% | Plowhorse |
| Seasonal risotto | 44 PLN | 14 PLN | 30 PLN | 12% | Star |
| “Chef’s special” pasta | 36 PLN | 17 PLN | 19 PLN | 3% | Dog |
Possible moves (still illustration): risotto gets steady exposure and a server recommendation; burger gets cheese portion control or supplier renegotiation, optionally +2 PLN while watching whether demand holds; bowl gets a better description and an add-on suggestion at order time; pasta is retired or rebuilt. None of these moves guarantees a lasting rise in average check. They only guarantee that decisions rest on margin per dish and sales, not on gut feel.
30-day menu engineering checklist
- Pick a category (for example mains). Do not mix the whole menu in one basket.
- Pull about 30 days of unit sales from POS or a ranking report.
- Fill in or update portion cost (recipe + supplier prices).
- Calculate margin per dish in PLN for each item.
- Calculate share and mark popularity against the chosen split line.
- Set average margin in the category and draw the 2×2 matrix.
- Assign actions: Star / Plowhorse / Puzzle / Dog.
- Choose 2–3 concrete changes per cycle (do not rebuild the whole menu at once).
- Save a baseline: unit sales, margin per dish, average check in the category or at the venue.
- After 2–4 weeks, compare the same numbers. Do not invent success “by feel.”
- Only then set rules for suggesting add-ons or combos around Stars and Puzzles (if you have Sales Engine).
- Plan the next audit after a supplier change, season shift, or larger menu rotation.
Reports and Sales Engine: where analysis ends and the manager’s decision begins
Analysis lives in reports. What the guest sees at order time comes from rules that the manager sets, not from “AI that optimizes the menu by itself.”
Sales Engine in OrderNow (Pro and Enterprise plans) includes, among other things:
- Smart Pairings: the manager assigns add-ons to dishes or categories,
- Combos: sets with slots and upcharges,
- measurement of how often the guest actually takes the suggested add-on (in the panel: Attach Rate), and revenue from recommendations,
- operation in QR menu, online ordering, and the server panel.
Suggestions follow rules from the panel. The module measures whether the guest adds an item. It does not promise a specific rise in average check up front.
Sensible sequence: 30 days of data → matrix in reports → 2–3 deliberate rules for suggesting add-ons or combos around Stars and Puzzles → measure how often guests accept them. Reversed order (add-ons first on blind faith, then “some analytics”) usually adds noise, not margin.
When menu engineering does not make sense (or not yet)
- The menu has 8 items and changes every week “from the head.” Stabilize the offer first.
- No recipes and no credible portion cost. Start with food cost and recipes.
- An extreme outlier period (renovation, opening, single event) as the only data window.
- The decision is already political (“we do not touch that item”). The matrix then only prices the cost of sentiment, not optimization.
- Expecting that drawing quadrants alone will raise average check without changing price, exposure, recipe, or recommendations.
Questions and answers
Is food cost percentage enough instead of margin per dish?
Not as a matrix axis. Food cost percentage helps control ingredient costs. Menu engineering compares how many zloty stay from a portion and how often you sell it. Details on calculating food cost: Food cost from POS.
How many days of data for the first audit?
Roughly about 30 days of representative sales. Shorter means more noise. Much longer makes it easier to lose the effect of recent supplier price changes. After large menu changes, run a separate cycle.
Do I have to remove all Dogs right away?
No. First check seasonality, image role, and the cost of keeping the item in inventory. The default hypothesis for a Dog is retirement or rebuild, but with context, not on autopilot.
Does Sales Engine choose what to promote on its own?
No. In OrderNow, Smart Pairings and Combos rules are set by the manager. The system shows suggestions by those rules and reports how often the guest takes an add-on and what revenue comes from recommendations. Matrix first, then 2–3 deliberate rules.
Which OrderNow plan includes reports and Sales Engine?
Basic sales reports: Start plan. Fuller analytics (including recipe-based food cost, peak-hour heatmap, export) and Sales Engine (add-on suggestions, combos, measurement of add-on take-up): Pro and Enterprise plans. Current scope: pricing, reports, Sales Engine.
What to do in the next 30 days
- Pull sales ranking and sales structure by category for the last 30 days.
- Close portion cost for top items in one category.
- Build the margin-per-dish (PLN) × popularity matrix and pick 2–3 moves.
- If you are on Pro/Enterprise: set 2–3 rules for suggesting add-ons around Stars / Puzzles and measure how often guests accept them, without promising “plus X percent to the check.”
Want to walk this path on your own data? Check reports and Sales Engine, or compare scope on pricing.
Sources
- Gastrowiedza: Menu Engineering 2.0
https://www.gastrowiedza.pl/baza-wiedzy/zarzadzanie-lokalem/inzynieria-menu-20-dane-pos
Menu engineering method based on POS data
- FoodShot: Menu engineering
https://foodshot.ai/pl/blog/menu-engineering
Overview of menu engineering practices in restaurant operations
- OrderNow: Reports and analytics
https://ordernow.pl/raporty-i-analityka
Scope of sales reports and category structure