Menu Intelligence
What is the menu engineering matrix, and how do you use it?
Menu engineering is the process of evaluating menu items by popularity and contribution margin to decide what to promote, reprice, rework, or remove. The standard matrix classifies items as stars, plowhorses, puzzles, or dogs based on whether their popularity and margin are high or low.
Reviewed by Quantiiv's restaurant analytics team · Updated
The traditional matrix is a useful industry starting point, not a complete decision method. Start by normalizing item and category definitions across POS systems and locations, then compare item-level unit sales within one consistent menu category and time period.
If reliable item-level variable cost is available, use it to calculate contribution margin. When cost data is not available, transaction-side analysis can still evaluate revenue, units, trend, basket value, customer dependency, daypart, channel, store variation, and price response without pretending margin has been measured.
For a multi-location or franchised brand, build both a systemwide view and store- or market-level views. The same item can be a star in one region and a puzzle in another. Corporate needs consistent definitions while each operator needs an answer that reflects the stores they actually run.
Menu engineering formulas
When reliable item-level cost data is available, use item-level POS sales and a consistent variable-cost definition. The same cost and category rules must apply to every item in the comparison.
Formula
Contribution margin per item = Selling price − Variable item cost
Popularity
Item units sold ÷ total units sold in the normalized, comparable menu category. Use a consistent period and apply the same modifier, size, and category rules across items.
High or low
Compare each item's popularity and contribution margin with a clear category threshold. Document the threshold so the quadrant can be reproduced.
The four menu engineering categories
The matrix narrows the operator question for each item. It does not prescribe the action on its own.
Star: high popularity, high margin
Protect consistency and visibility. Before increasing price, confirm the item can take the change without giving back traffic or attached sales.
Plowhorse: high popularity, low margin
Review price, portion, cost, and basket role carefully. Guests already choose it, so a blunt change can put valuable demand at risk.
Puzzle: low popularity, high margin
Test placement, naming, bundling, or server prompts. First verify that the item's margin opportunity is large enough to matter.
Dog: low popularity, low margin
Investigate before removing it. A low-volume item may retain a loyal niche, complete high-value baskets, or matter in only a few markets.
Worked menu engineering example
This hypothetical category shows why the quadrant is a prompt for the next question, not a final recommendation.
| Item | Popularity | Contribution margin | Quadrant | Next question |
|---|---|---|---|---|
| Classic entrée | High | High | Star | Can it take price without losing visits or attachments? |
| Value entrée | High | Low | Plowhorse | Does it drive traffic or profitable add-ons? |
| Premium entrée | Low | High | Puzzle | Is demand limited by awareness, placement, or price? |
| Niche entrée | Low | Low | Dog | Who buys it, and what else is in those baskets? |
Where the traditional matrix stops
Store and channel variation
A systemwide classification can hide an item that performs differently by market, daypart, delivery channel, or store format.
Basket value
An item's own margin misses the drinks, sides, desserts, and upgrades it brings into the order.
Guest dependency
A low-volume item may matter to a small group of high-frequency guests. Removing it can change more than item sales.
Price response
The matrix describes performance at current prices. It does not predict how demand will respond to a new one.
Why it matters
Menu engineering turns item-level POS data into a short list of actions: protect the stars, improve the plowhorses, create demand for the puzzles, and investigate the dogs. Its value comes from narrowing the decisions; store-level, basket, and elasticity evidence determine the right move.
Frequently asked questions
How often should a restaurant update its menu engineering matrix?
Refresh it after a meaningful menu or price change and on a regular operating cadence. Use enough history to avoid reacting to one unusual week, but do not let seasonal or channel changes disappear inside an annual average.
Should a restaurant remove every dog from the menu?
No. First check the item's trend, operational burden, basket attachment, guest dependency, and store-level variation. Remove or rework it only when the broader evidence supports the change.
Is food-cost percentage enough for menu engineering?
No. When reliable item-level cost exists, food-cost percentage describes cost relative to price while contribution margin shows dollars contributed before fixed costs. The matrix also needs popularity, and the final decision needs trend, basket, customer, store, channel, and price-response context.
Sources and further reading
How Quantiiv Puts This to Work
Menu Engineering
“Which items actually drive our revenue and margin, and how should the menu change?”
See the solutionMenu Rationalization
“Our menu has gotten too big. Which items can we actually remove without losing the customers attached to them?”
See the solutionFranchise Analytics
“How do we get real visibility across franchisees, give each operator access to only their stores, and turn the data into action?”
See the solutionStop Fighting Your Data.
Start Using It.
Transform fragmented restaurant data into actionable insights—with just an email to ROGER.
400+
Locations Served
15+
POS Integrations
10hrs
Saved Per Week
Powered by Quantiiv
Enterprise Restaurant Intelligence