Menu Engineering: Which Dishes Actually Make You Money?

Take two dishes. A chicken plate sells for $24 and costs $7.20 to produce: a 70% margin, $16.80 of contribution. A lamb chop sells for $56 and costs $25.20: a 55% margin, $30.80 of contribution.

Look at percentages and chicken wins comfortably. Look at what lands in the till and lamb wins by nearly double. You pay staff wages in dollars, not in percentages, which means the second number is the one that matters.

That single distinction is where most menu engineering goes wrong, and it is the reason many operators optimize their menu into lower profit while every ratio on the spreadsheet improves. This guide walks through the actual method, adds a correction almost nobody applies (delivery platform commissions), and draws an honest line around what AI can and cannot do with your POS data. If you want the wider view of where AI fits across sectors, our 2026 AI-by-industry map is a good starting point.

What is menu engineering, and what two numbers does it use?

Menu engineering plots every item on your menu against two axes: its share of total units sold (popularity) and its contribution margin in currency, not percentage. Michael Kasavana and Donald Smith formalized the method at Michigan State University in 1982. Items land in one of four quadrants, and each quadrant gets a different action.

The quadrants are Stars (sell well, contribute well), Plowhorses (sell well, contribute little), Puzzles (sell rarely, contribute well), and Dogs (sell rarely, contribute little).

So far, standard. The part most articles get wrong is the second axis. The original model asks for contribution margin in dollars, and swapping in gross margin percentage flips the results. Food cost percentage is a useful operational control. It is not a profitability ranking.

How do you calculate contribution margin and the thresholds?

Contribution margin equals menu price minus portion food cost. Total contribution equals that figure multiplied by units sold. Which quadrant an item falls into depends on two thresholds, and both get miscalculated routinely.

The popularity threshold is (1 divided by the number of items on the menu) multiplied by 0.70. On a ten-item menu that gives 7%; on twelve items, 5.8%. Anything above the threshold counts as high-popularity.

That 0.70 multiplier is not arbitrary. Using the flat average (10% on a ten-item menu) assumes every dish sells equally, which no real menu does. The multiplier makes room for the natural skew in sales. Skip it and you will label half your menu as underperforming when it is simply behaving normally.

The profitability threshold is the weighted average contribution margin, meaning total contribution divided by total units sold. Not the plain average of the item margins. An expensive dish that sells three times a month can drag a plain average upward and push genuinely healthy items below the line.

What does the math look like on a real menu?

Four items from a brunch cafe, with monthly volumes:

• Full brunch platter: price $34, cost $13.60, contribution $20.40, 210 sold, total contribution $4,284
• Scrambled eggs: price $11, cost $3.85, contribution $7.15, 480 sold, total contribution $3,432
• Toasted sandwich: price $8, cost $3.30, contribution $4.70, 520 sold, total contribution $2,444
• Avocado toast: price $14, cost $6.40, contribution $7.60, 60 sold, total contribution $456

On an eight-item menu the popularity threshold is (1/8) x 0.70 = 8.75%. These four sold 1,270 units between them; eggs and the sandwich sit comfortably above the line, avocado toast well below it.

The platter is a Star, eggs and the sandwich are Plowhorses, avocado toast is a Puzzle. Notice what the ranking exposes: the best-selling item on the list, at 520 units, generates barely half the contribution of the platter at 210 units. The kitchen assembles that sandwich 520 times a month to earn less than half of what a dish made a fifth as often brings in.

Operators tend to treat the top-selling dish as the flagship. The first thing menu engineering usually reveals is that the flagship is carrying traffic, not profit.

The move here is not to delete the sandwich. Plowhorses respond to two levers: reduce portion cost (supplier, gram weight, waste) or raise price modestly. Because the volume multiplier works in your favour, small changes compound fast. Adding $0.60 to that sandwich is $312 a month from one line item.

Why does a delivery platform need its own matrix?

Because commission is charged on the sale price, not on the cost, it eats contribution margin disproportionately. Delivery platform commissions typically run between 15% and 30%, and in some markets and contract tiers considerably higher. An item that is a Star in your dining room can be a Dog on the platform, and one combined report will never show you that.

Take the scrambled eggs above: $11 price, $3.85 cost, $7.15 contribution in-house. Sold through a platform at 25% commission you keep $8.25, and after $0.50 of packaging the contribution drops to $3.90. Same dish, same kitchen, 55% of the profit.

The most common mistake we see is treating commission as overhead. It is not overhead, it is a variable cost tied to a specific unit of a specific product, and it belongs inside the contribution calculation. The fix is to build two matrices: one for dine-in and pickup, one for delivery. Most modern POS systems let you set channel-specific pricing for the same item, so acting on the finding is usually a configuration change rather than a project. If your delivery volume is significant, our piece on turning order data into profit covers the surrounding operational picture.

Where does AI genuinely help with this?

AI is not the part that does the arithmetic. It is the part that prepares the data going in and interprets the results coming out. That distinction matters because large language models are unreliable at multi-step calculation. Benchmarks of spreadsheet tasks put the best models around 77% accuracy, and performance on multi-variable computation collapses well below that. Accuracy improves sharply when the model calls code or a spreadsheet instead of computing in its own head.

Practical rule: let a spreadsheet do the multiplication, let the model do the reading. Within that boundary, four jobs pay off quickly:

• Product name normalization. Your POS almost certainly holds "Latte", "LATTE Lg", "latte large" and "Latte (L)" as four separate lines. Collapsing them by hand is a day of work; a model does it in half an hour.
• Recipe and cost drafting. A model can draft a recipe and cost breakdown from the item name. You verify gram weights and waste percentages. Skipping that verification means building the whole matrix on a wrong cost base.
• Anomaly detection. When one item's portion cost quietly climbs 20% in a month, the model surfaces it in the report instead of you finding out at quarter end.
• Market basket analysis. Which items get ordered together, drawn from ticket-level data. That is the subject of the next section.

What stays human: verifying gram weights and waste, assigning channel costs correctly, and deciding why an item is on the menu at all. A dish may be there to pull traffic, to serve the kids' menu, or because it is your signature. No model knows that.

Why is "cut the Dogs" dangerous advice?

Deleting low-popularity, low-margin items is the most frequently given and most quietly damaging recommendation in menu engineering. The matrix evaluates each item in isolation, but customers do not buy items in isolation, they buy tickets. Before you cut anything, look at what it gets ordered alongside.

That is what market basket analysis does: it mines ticket-level data for rules of the form "when A is ordered, B is ordered too", classically with the Apriori algorithm and, at scale, the faster FP-Growth. The findings can stop you mid-decision. A low-margin kids' plate that consistently appears next to two full-price adult mains is not a Dog. Removing it can cost you the whole table.

The model has a second known limitation worth stating plainly: it excludes labour and fixed costs. That systematically flatters labour-intensive dishes, a critique Pavesic raised back in 1983 and one that still holds. If a dish shows a healthy contribution margin but takes fifteen minutes of skilled hands to plate, factor the kitchen minutes in yourself.

Which menu design tips are actually evidence-based?

The second half of most menu engineering articles turns to design advice, and the quality of evidence behind those tips varies enormously. Three worth separating.

Removing the currency symbol has the strongest support. A 2009 Cornell study with 201 diners found that dropping the dollar sign next to the price raised average spend per person by roughly 8%. Writing prices out in words produced no additional benefit. But this was one restaurant, one meal period, in 2009, and it has not been replicated across currencies. Treat the direction as sound and the magnitude as untested, then test it on your own menu.

The "golden triangle" or sweet spot has largely been debunked. A 2012 eye-tracking study found that diners do not scan menus the way the industry assumed; they read them substantially like a book, front to back. Claims that moving an item to a specific corner lifts its sales by 20-30% trace back to consultancy case studies, not peer-reviewed work.

Anchoring is conceptually reasonable but has no measured effect size in a restaurant menu context. Putting an expensive reference item on the menu is not wrong. If you meet a specific percentage attached to it, ask where the number came from.

Common questions

What should my food cost percentage be?

The commonly cited target band is 25-35%, with industry averages landing near 32%. If a large share of your volume comes through delivery platforms, aim at the lower end, because commission adds a cost that never appears in your food cost line.

Should I remove a low-selling but profitable dish?

Not first. Try three things: rename it more appetizingly, move its position, and instruct staff to recommend it. The definition of a Puzzle is "profitable but unnoticed". Removal is the last resort, not the first.

How do I get this data out of my POS?

Nearly every POS exports to spreadsheet or CSV from its reporting screen, and item-level units sold plus revenue is enough to start. You will need to add the cost column yourself, because recipe costs in most systems are either empty or stale. For market basket analysis, ask specifically for ticket-level line data; a summary report will not do.

How often should I redo this?

Quarterly, and more often when input costs are moving fast. An annual menu engineering exercise is already out of date by the second quarter.

Where to start

• Export one month of POS data. Item name, units, revenue. This is the easiest step and the one that gets postponed indefinitely.
• Cost your top 20 sellers properly. A matrix built on estimated costs dresses bad decisions up in numbers. Include waste percentages.
• Split by channel. Calculate contribution separately for dine-in and delivery, and treat commission as a variable cost rather than overhead.
• Work on Plowhorses first. The fastest gains come from small cost or price adjustments on high-volume items, where the unit multiplier does the heavy lifting.
• Use AI for normalization, anomalies and basket analysis, not for arithmetic. Keep the math in a spreadsheet.

Menu engineering is not a one-off project, it is a short habit repeated every quarter. On the first pass you will almost certainly find that a third of your menu sits somewhere other than where you assumed. If you get stuck turning your own POS export into a working matrix, send it over and we will take a look together.