Tech Tuesday: Detecting Menu Bloat with Menu Engineering Data
Imagine a regional restaurant chain with 120 menu items. The menu looks impressive… but the kitchen is stressed, training takes forever, and half the inventory feels “just in case.”
That’s menu bloat in real life: too many items, too many ingredients, and too many operational failure points.
Today’s Tech Tuesday is about the data-driven way restaurants detect bloat: menu engineering—a simple framework that combines popularity and profitability to decide what stays, what gets fixed, and what gets cut.
Technical Deep Dive
Menu engineering is often taught using a four-quadrant model: Stars, Plowhorses, Puzzles, Dogs. It’s widely used in restaurant operations and training because it’s easy to calculate and easy to act on (see examples from ServSafe Brands and an overview from Toast).
Step 1: Capture the essential data fields
At minimum, you need item-level data for a time window (often 4–13 weeks):
- ItemName
- UnitsSold
- MenuPrice
- PortionCost (standard recipe cost)
Step 2: Compute profitability
Contribution Margin (CM) is the most common profitability metric:
CM = MenuPrice − PortionCost
This definition is consistent across common training references (example: OpenTextBC, and industry tooling explanations like CrunchTime).
Many operators also track Food Cost % because it flags items that “look popular” but are financially heavy:
FoodCost% = PortionCost ÷ MenuPrice
(See common field definitions and examples in restaurant accounting software writeups such as Restaurant365.)
Step 3: Compute popularity
Popularity is usually measured as Menu Mix % (a.k.a. sales mix or velocity):
MenuMix% = UnitsSold ÷ TotalUnitsSold
Step 4: Choose thresholds (the “bloat detector” part)
You need two cut lines: one for profitability and one for popularity.
- Profitability threshold: compare each item’s CM to the Average Contribution Margin (ACM).
- Popularity threshold: compare each item’s MenuMix% to a target popularity level.
Average Contribution Margin:
ACM = (Σ CM × UnitsSold) ÷ (Σ UnitsSold)
(This ACM concept is explained in standard menu engineering teaching materials such as OpenTextBC.)
Popularity threshold (simple version):
ExpectedMix% = 1 ÷ N
Where N is the number of items in the category (e.g., 12 appetizers). Many operators use a fraction of ExpectedMix% as the “popular enough” cut line (for example, 70% of ExpectedMix%) depending on concept and category behavior.
Step 5: Classify items into the 4 quadrants
- Stars: High MenuMix% and High CM (protect, feature, don’t mess them up)
- Plowhorses: High MenuMix% and Low CM (popular but not profitable—rework portioning, pricing, or bundling)
- Puzzles: Low MenuMix% and High CM (profitable but not ordered—rename, reposition, photo, server suggestion)
- Dogs: Low MenuMix% and Low CM (prime “menu bloat” candidates—consider cutting)
This quadrant language is consistent across many industry references, including ServSafe Brands and professional service perspectives such as Baker Tilly.
A tiny pseudo-code example
// Inputs: UnitsSold, MenuPrice, PortionCost (per item), plus total units
CM = MenuPrice - PortionCost
MenuMixPct = UnitsSold / TotalUnitsSold
// Profit threshold (ACM computed across category or whole menu)
isHighProfit = CM >= ACM
isPopular = MenuMixPct >= PopularityThreshold
if (isPopular && isHighProfit) => STAR
if (isPopular && !isHighProfit) => PLOWHORSE
if (!isPopular && isHighProfit) => PUZZLE
if (!isPopular && !isHighProfit) => DOGFood / Kitchen Analogy
Think of your menu like a spice cabinet.
If you have 60 spices but only use 15, the cabinet gets chaotic. Things expire. You buy duplicates. Cooking slows down because you’re hunting instead of cooking.
Menu engineering is the “spice cabinet audit.” It tells you what gets used (popularity) and what actually improves the meal (profitability). Menu bloat is what happens when you keep everything “just in case.”
Practical Food Connection
Here’s how large-scale restaurants gather these data points in the real world (and how a serious chain does it without guesswork):
1. POS transaction logs (popularity, modifiers, timing)
- Units sold by item, store, daypart
- Modifier frequency (add cheese, no sauce, extra protein)
- Discount/promo impact
- Ticket time and throughput measures
This POS-driven approach is the backbone of modern menu optimization (see examples described by POS vendors and operations writeups like Mentor POS).
2. Recipe costing systems (profitability)
- Standard portion costs pulled from recipes (ingredients + yields)
- Vendor price updates (weekly or monthly)
- Yield loss assumptions (trim, cooking loss)
3. Inventory and waste tracking (the “hidden bloat” signal)
- Spoilage and waste by ingredient
- Low-turn ingredients that exist “for one menu item”
- Variance between theoretical vs actual usage
When a menu item requires rare ingredients that don’t move, bloat shows up as waste and inventory complexity—often before it shows up in customer complaints.
4. Labor + complexity metrics (optional, but powerful)
- Prep time per item
- Station congestion (where bottlenecks form)
- Training time and error rates
Two items can have identical CM and sales, but one may be “operationally expensive” because it disrupts flow. This is one reason simplified menus can improve speed and consistency (for example, during pandemic-era menu reductions reported by sources like Reuters and industry coverage such as Restaurant Business).
Menu bloat feels like “more value,” but data often reveals the opposite: more inventory, more training, more errors, more waste—and less consistency.
Menu engineering gives you a calm, repeatable way to shrink a menu without guessing. Protect the Stars. Fix the Plowhorses. Market the Puzzles. And be brave enough to cut the Dogs.
Tomorrow we’ll talk about what bloat does to kitchen execution—because the kitchen always pays the bill for a menu that got too ambitious.
Comments