Menu engineering scores every dish on units sold against contribution margin in dollars, then splits high from low volume at 70% of average units sold, a threshold the four box grids published online almost never state.
Skai Solutions works with Australian and New Zealand venues on the orders that never reach the menu at all, so we have read a lot of menu analysis and watched where it goes wrong. This page sets out the original Kasavana and Smith method properly: the two axes and why one of them is dollars rather than a percentage, where the volume line actually sits, the five steps in order, and the four things the method cannot see.
It is one specific method, not a general idea about menus. Kasavana and Smith set it out in Menu Engineering: A Practical Guide in 1982, and the whole method is this: score every item on your menu against two axes, how many you sell and how much cash each one leaves behind, then act differently on each of the four groups that fall out.
The two axes are the part people get wrong. The second axis is CONTRIBUTION MARGIN IN DOLLARS, which is the selling price minus the food cost of that item. It is not food cost percentage. A A$42 steak at 38% food cost leaves A$26.04. A A$9 side of chips at 18% food cost leaves A$7.38. The chips look better on a percentage report and the steak pays the rent.
That single swap is why the method survived. It replaced an earlier model, Miller's, which split items on food cost percentage, and a percentage split systematically promotes cheap high margin lines and demotes the expensive dishes that actually fund the business.
| Category | Sells | Contribution margin | What you do |
|---|---|---|---|
| Stars | High | High | Nothing. Protect the recipe, the position on the menu and the price. |
| Plowhorses | High | Low | Raise the margin without touching demand: portion, garnish, a small price move. |
| Puzzles | Low | High | Sell more of it: reposition, rename, brief the floor, or accept it is a special. |
| Dogs | Low | Low | Remove it, unless it is on the menu for a reason the numbers cannot see. |
Those are the original names and they are worth keeping, because every piece of software that draws this grid uses them and you will otherwise end up with four terms nobody else recognises.
This is the number almost nobody publishes, and getting it wrong is how a working menu gets cut to pieces.
The volume axis in the Kasavana and Smith model is not set at the average. It is set at 70% of average units sold. A peer reviewed comparison of the menu analysis models in FIU Hospitality Review, Fall 2007 labels that axis on the model diagram as "70% average units sold", and records that the Miller model it displaced used a 70/30 split of its own on food cost percentage.
Work it through. If your menu has 20 items, the average item takes 5% of covers. Seventy per cent of that is 3.5%. So an item is high volume if it sells 3.5% of covers or more, not 5% or more. The arithmetic is 0.70 divided by the number of items on the menu.
The consequence is large. On a 20 item menu, every item selling between 3.5% and 5% of covers is correctly a high volume line. Split at the plain average and all of them get labelled low volume, which turns Plowhorses into Dogs and Stars into Puzzles. If you have ever run this exercise and been told to delete a third of your menu, this is probably why.
And note the second order effect: the threshold moves when the menu length moves. Cut a 20 item menu to 15 and the bar rises from 3.5% to 4.67% of covers. Items that were performing become underperformers on paper without a single customer changing their mind.
Five steps, and the first one is where most attempts stop.
One, get item level sales counts. Units sold per item, over a period long enough to be real, which in a venue with a weekly rhythm means at least four weeks. This has to come from the till, which is why it is impossible on a register that only totals, as our cash register against POS page explains.
Two, cost every recipe. Not estimate. Weigh it. The cost of a plate is the sum of its components at your current invoice prices, which move. Our food cost percentage page covers the venue level number; this is the item level version of the same work, and it is slower.
Three, work out each item's contribution margin. Selling price minus item food cost, in dollars. Then the menu average contribution margin, weighted by units sold rather than a plain average of the items, because an item you sell twice a week should not pull the bar.
Four, set the two lines. Contribution margin above or below the weighted average, and volume above or below 0.70 divided by your item count. Four quadrants, every item in one.
Five, act by quadrant, and change one thing at a time. A Plowhorse gets a margin fix. A Puzzle gets a demand fix. If you change the price and the position and the description in the same week, you have learned nothing about which worked.
Four real limits, and an honest page has to carry them.
It ignores labour entirely. Contribution margin is price minus food cost. A dish with A$26 of margin that takes eleven minutes of a chef's hands is not better than a A$19 dish that takes two, and the model cannot see the difference. If labour is your problem rather than food cost, the number to look at is sales per labour hour, and the whole picture sits in prime cost.
It treats items as independent. Remove a Dog that three regulars come in for and you lose the table, not the dish. Remove the only vegetarian main and you lose the group booking that could not agree anywhere else.
It is blind to why something sells. A Star may be a Star because it is second on the list and priced next to something expensive. The model reports the outcome and attributes nothing.
It assumes your costings are current. They are not. Every invoice moves and nobody recosts a whole menu monthly. A quarterly rerun with honest costings beats a weekly one on stale numbers.
One more caution that comes up constantly. The Australian Taxation Office small business benchmarks give average cost of sales of about 35% for restaurants and 38% for coffee shops. Those are VENUE level shares of turnover and they are useful for checking whether your whole business sits in its band, which our overhead costs page does. They are not item level targets and no individual dish has to hit them.
Menu engineering prices a dish for a table. Pricing the same kitchen for a function is a different sum, with travel, hire and weekend labour in it. That one is on our page on how much to charge for catering.
Menu engineering needs item level sales data, which means it depends on what your POS actually records and exports. Our page on the Revel POS integration sets out how item and modifier data moves in one such system.
Say it plainly. If your menu has fewer than about a dozen items, you already know which two sell and which one does not, and a four box grid will tell you that at the cost of a weekend. If you cannot get item level sales counts out of your till, do not start, because the exercise is only as good as step one and an estimated sales mix produces confident nonsense. And if your current problem is that you are turning away trade rather than mispricing it, this is the wrong tool entirely.
That last one is the common case in our experience. A venue that misses a dozen calls across a Friday service is losing bookings worth more than any margin fix on the menu will return that month, and it will not show up in any menu report, because an order nobody took is not an item that failed to sell. Skai Solutions exists to close that specific gap, and setup takes about five days. Our no-shows page has the comparable arithmetic on the booking side.
Menu engineering is worth doing when the menu is long, the sales data is real and the recipe costs are current. In that case it is one of the few pieces of restaurant analysis that pays for the afternoon it takes. Just set the volume line at 70% of average, not at average.
What is menu engineering?
A method set out by Kasavana and Smith in 1982 that scores every menu item on two axes, units sold and contribution margin in dollars, then groups items into Stars, Plowhorses, Puzzles and Dogs and prescribes a different action for each. The key detail is that the margin axis is dollars of contribution, not food cost percentage, which is what separates it from the earlier Miller model.
What are the four menu engineering categories?
Stars are high volume and high contribution margin, so you protect them. Plowhorses are high volume and low margin, so you raise the margin without disturbing demand. Puzzles are low volume and high margin, so you work on demand. Dogs are low on both and usually come off the menu, unless they are there for a reason the numbers cannot see.
Where do you draw the line between high and low volume?
At 70% of average units sold, not at the average. The arithmetic is 0.70 divided by the number of items on the menu, so on a 20 item menu an item is high volume if it takes 3.5% of covers or more. A peer reviewed comparison of menu analysis models in FIU Hospitality Review, Fall 2007, labels the volume axis of the Kasavana and Smith model as 70% average units sold.
Should I use contribution margin or food cost percentage?
Contribution margin in dollars. A A$42 main at 38% food cost leaves A$26.04 and a A$9 side at 18% leaves A$7.38, so a percentage ranking promotes the side and demotes the dish paying your rent. Splitting on food cost percentage is the Miller model, and menu engineering exists because that split produced the wrong instructions.
Does menu engineering account for labour?
No, and that is its biggest blind spot. Contribution margin is selling price minus food cost only, so a high margin dish that takes eleven minutes of skilled hands scores better than a quick one that earns slightly less. If labour is the constraint, look at sales per labour hour and prime cost instead.
How often should you redo it?
Quarterly, with recosted recipes, beats monthly on stale costings. The output is only as good as two inputs, current item food costs and real item level sales counts from the till, and both drift. Also remember the volume threshold moves whenever the menu length changes, so a shorter menu raises the bar every item has to clear.