Menu engineering, done properly

What is menu engineering, and why does it still work in 2026?

Menu engineering is a sorting exercise. Plot every dish on two axes, how often it sells, and how much rupee margin each plate leaves behind, and it lands in one of four boxes:

Two thresholds draw the lines. A dish counts as popular if it sells above roughly 70% of the average per-dish count, the classic heuristic, and a sensible default. A dish counts as profitable if its rupee margin per plate beats the sales-weighted average margin of the whole menu. Note the unit: rupee margin, not food-cost percentage. A dal at 22% food cost leaving ₹194 a plate is a weaker earner than a mutton curry at 38% leaving ₹277. Percentages belong in reports; rupees go in the bank.

The exercise earns its keep in India for three reasons. Indian casual-dining menus run long, cards with 60 to 120 items are common, and long menus hide dishes nobody has costed since the card was printed. Ingredient inflation re-costs your kitchen every quarter whether or not you re-cost the menu. And most Indian menus carry deliberate cross-subsidies, breads and rice priced soft to flatter the mains, which only work if someone is actually checking the math.

Operators who run the matrix quarterly with real recipe costs typically report gross-margin gains of 3–7 percentage points, mostly from repricing plowhorses and cutting dogs. Treat that as typical operator experience, not a promise, but it recurs for a structural reason: the gains ride demand you already have instead of demand you must buy.

How do you get a true per-dish cost?

The matrix is only as honest as its cost column, and this is where most attempts die. Three rules:

Cost the recipe, not the shopping list. A kilo of raw chicken does not yield a kilo of servable chicken; vegetables trim down; frying absorbs oil. Cost at usable yield, and include the things menus forget, the butter brushed on the naan, the garnish, the papad and pickle that ride along free.

Cost sub-recipes once, then reuse them. A makhani gravy might sit under six dishes; a fried-rice base under four. Cost the gravy per litre as its own recipe, and every dish built on it updates automatically when tomato prices move. This single habit turns per-dish costing from a weekend project into an hour.

Refresh purchase prices quarterly. A matrix built on last year's chicken price will confidently point you at the wrong dishes. Recipe costs must track what you actually paid last month, not what the rate card said at opening.

The food-cost guide covers yields, sub-recipes and variance in depth, and the food-cost calculator does the per-dish arithmetic. As a sanity check: a healthy Indian kitchen blends to 28–32% food cost overall. If your blended number sits in that band, the matrix will still find leaks, that is the whole point.

How do you build the matrix? A 20-dish worked example

The method: pull a full month of per-dish sales counts from your POS, attach the per-plate ingredient cost, compute margin (price minus cost), then draw the two lines, popularity at 70% of the average per-dish count, profitability at the sales-weighted average margin.

The table below is a worked, illustrative example, a composite of a typical North Indian casual-dining menu with realistic numbers, not data from any real restaurant or customer. Across these 20 dishes: 7,420 plates a month, an average of 371 plates per dish, so the popularity line sits at about 260 plates; the sales-weighted average margin works out to about ₹151, which is the profitability line.

Read what the averages hide. This menu does roughly ₹15.8 lakh of monthly revenue at about ₹11.2 lakh gross margin, a blended food cost near 29%, comfortably inside the healthy 28–32% band. And yet the matrix finds six plowhorses and three dogs. A menu can look fine as an average and still leak dish by dish; the matrix exists to make each leak visible and give it a name.

Notice also who the plowhorses are: the breads, the rice, the lime soda, the highest-volume lines on the card, plus two dishes (veg biryani, chilli chicken) whose ingredient costs have quietly outrun their prices. That pattern shows up in almost every Indian casual-dining room.

What should you do with each quadrant?

Stars: protect, then promote. Do not fiddle with a star's price casually, these dishes carry the room. Protect them operationally: spec cards and portion checks, because a star that gets inconsistent becomes a complaint machine. Then promote them, anchor combos on them, place them where eyes land first (menu-placement psychology is a heuristic, not a law, but the top-right of a panel and the first item of a section demonstrably get read). Never discount a star to fill seats; you are paying people to order what they already order.

Plowhorses: this is where the money is. High volume, thin margin, small price moves multiply across hundreds of plates. In the worked menu, garlic naan at ₹75 sells 940 plates a month; moving it to ₹85 adds about ₹9,400 of monthly margin, and naan demand is anchored to the mains it accompanies. Jeera rice at ₹149 moving to ₹159 adds about ₹4,600 more. Two quiet reprices, roughly ₹14,000 a month, over a full point of gross margin on this menu, from ten minutes of decisions. Where the price genuinely cannot move (competitive anchors like tea or lime soda), re-cost instead: portion spec, yield discipline, a cheaper garnish. Chilli chicken at 40% food cost is not a pricing problem, it is a recipe drifting from its spec.

Reprice in small steps, one print cycle at a time, and watch weekly counts for a month after each move. Run any plowhorse through the calculator, current ingredient cost in, target food-cost percentage in, required price out:

Puzzles: reposition before you touch the price. These earn well but sell poorly, usually a visibility or confidence problem. Rename and describe them, specifics sell, and a one-line description of how the rogan josh is cooked does more than a price cut. Put a photo on the QR menu. Give servers a single suggestion line for tables that order naan and nothing else exciting. Move the dish next to a star on the card. If a puzzle refuses to move after a genuine quarter of promotion, it may simply be on the wrong menu.

Dogs: cut, with a short appeals process. Every dog you remove simplifies inventory, shortens prep and frees a slot for something that earns. The only reprieves: a dog that exists to complete a set (a dessert on a family menu can be bundled into a thali or combo instead of sold alone), or one with a loyal high-value table attached. Otherwise the rule is simple, two consecutive quarters in the dog box and it comes off the card.

Should your delivery menu be its own matrix?

Yes, and this is the step most operators skip. Aggregator commissions and packaging costs come off every delivered plate, so per-dish margin on delivery is a different number than dine-in, a dine-in star can be a delivery dog once the platform takes its slice and the packaging is paid for. Run the delivery menu as a separate matrix with delivery-only sales counts and delivery-adjusted margins, and gross up delivery prices dish by dish, the menu price calculator does the backsolve, rather than slapping one blanket percentage on the card. Tax treatment differs on delivery too, the GST guide covers where liability sits. And some dishes should exit the delivery card entirely for travel reasons: a dish that arrives soggy generates refunds and one-star ratings no margin can pay for.

How often should you rerun the numbers?

Quarterly is the cadence that works, often enough to catch ingredient-price drift, rare enough to let each change show its effect. Add trigger-based reruns on top: before any menu reprint, after a genuine supplier price shock, when the season flips the card, and six weeks after any new dish launches (long enough to call it a star or a puzzle honestly). Menu engineering is the first lever of average ticket, which makes it the first chapter of any serious growth plan, the guide to increasing restaurant sales ranks it against every other move by ROI. Once the data exists, a rerun is one evening of work. The first run is the expensive one.

Can software run the matrix for you?

You can absolutely do this in a spreadsheet: export item-wise sales, attach recipe costs, sort twice, classify. It works, once. The discipline usually dies by the third quarter, because the export-attach-sort loop is exactly the kind of chore that loses to a busy Friday.

The structural fix is to let the systems that already hold both datasets do the join. Your billing layer already counts every dish sold; recipe-linked inventory already knows what each plate costs, updated as purchase prices change. CountStand is an AI-native restaurant operating system for India, offline-first billing, KDS, inventory, GST & compliance, and an autonomous AI manager, in one platform, from ₹999/mo per outlet. Because billing and recipes live in one system, the quadrants compute themselves: the menu report classifies every dish continuously, flags plowhorses whose food cost has crossed threshold, and puts the reprice candidates in front of you at day-close instead of waiting for the quarter you never get to. If you want to see your own menu sorted this way, book a demo, bring last month's card. The broader case for running the room on one system is on the POS software page.