menu_engineering v1.0.0

name: "menu_engineering" description: "Engineer a restaurant menu from sales and margin data: classify every item by popularity and dollar contribution margin into Stars, Plowhorses, Puzzles, and Dogs, then change placement, descriptions, and prices by class and re-measure after one full cycle. Ships a tested classifier and comparator, a worksheet layout, and a fully worked eight item menu with a measured second month. Use when analysing menu profitability, deciding which dishes to cut, reprice, rename, or feature, or checking whether a menu change actually paid." metadata: { "includeInPrompt": true }

Menu Engineering

Purpose

Food cost percent alone misleads. An item can post the worst food cost percent on the menu and still put the most dollars in the till, and the best percent item can earn almost nothing if nobody orders it. Menu engineering fixes that by judging each item on two facts together: how many sold, and how many dollars each sale contributes after plate cost. This skill runs the Kasavana and Smith classification, turns each class into a specific change list covering placement, naming, and price, and then re-measures after a full cycle so changes are kept or reverted on evidence. It covers restaurants, cafes, bars with food, and institutional food service. It does not cost recipes from scratch, set a whole pricing strategy, or give tax or employment advice.

Workflow

1. Fix the period and the categories

• Analyse one category at a time: starters, mains, desserts, drinks. Never classify across categories, because items only compete with the items a guest chooses between.
• Use one full period of point of sale data, two to four weeks at minimum, a month is better. Note promotions, holidays, closures, and weather events inside the period on the worksheet, because they bend popularity and will bend the comparison later.
• Pull three facts per item: units sold, menu price before tax as actually charged, and plate cost from the current standard recipe costing. Recost any item whose main ingredient price has moved since the costing was written. A classification built on stale plate costs is fiction with tidy formatting.

2. Run the classification

• Contribution margin per item is price minus plate cost, in dollars. Classify on dollars, not on food cost percent.
• Popularity cutoff: expected popularity is 1 divided by the number of items in the category, and an item counts as popular when its share of category units is at least 70 percent of expected. With 8 items the cutoff is 8.75 percent of category units.
• Profitability line: the weighted average contribution margin of the category, which is total contribution divided by total units sold. At or above the line counts as profitable.
• Run bin/menu_engineering.py on a CSV with columns item, category, units_sold, price, plate_cost. It prints each item's mix, margin, total contribution, class, and the price that item would need to reach the category average margin at its current plate cost. Add --format md for a worksheet table or --json for machine readable output.
• Classes: Star is popular and profitable. Plowhorse is popular and not profitable. Puzzle is not popular and profitable. Dog is neither.

3. Sanity check before acting on any label

• Read the gap, not just the quadrant. An item $0.40 under the average margin or 20 units under the popularity cutoff is borderline and flips on small moves. Mark borderline items and treat their labels as provisional.
• Flag labour. The classic model counts food cost only. Note any item with heavy prep or peak time station load next to its row, and weigh that before promoting it or cutting it. A low margin item that is also slow to fire is worse than its row, and a simple item with a thin margin may be fine.
• Check roles the numbers cannot see: the only vegetarian or kids option in a category, the item a regular segment travels for, and items that share ingredients with a Star. A Dog doing one of those jobs gets kept and de-emphasised, not cut.
• Confirm the totals. Category revenue and total contribution from the classifier must tie to the point of sale report for the period. If they do not, the input data is wrong and no class is trustworthy yet.

4. Write the change list by class

• Stars: protect recipe and portion, give them the strongest section positions, never discount them. Full handling per class is in references/change-playbook.md.
• Plowhorses: raise price in small steps, trim plate cost where the guest cannot see it, and move them to quieter positions to shift some demand toward Stars and Puzzles. Use the price to reach average margin as a ceiling for the discussion, never as a single jump.
• Puzzles: rename with an honest descriptive label, move to the first, second, or last slot in the section, brief servers to recommend them by name, and add a low risk trial format. Try a price cut only after a full cycle of visibility changes.
• Dogs: remove them, or give one rework chance when a single clear cause shows up, then reclassify after one cycle. Keep and de-emphasise Dogs that carry dietary coverage or a traffic role.
• Change one lever per item per cycle: price, position, or name. Changing all three at once makes the result unreadable. Log every change with date, old value, new value, and the class based reason.

5. Apply placement and price presentation rules

• Put Stars and the Puzzles being pushed in the first or last positions of each section, where reading and recall are strongest. The middle of a list gets skimmed.
• Use boxes, photos, and house tags on at most one or two items per section. Emphasis spent on everything emphasises nothing.
• Print prices as bare numerals in the description's type size at the end of the description. Avoid a lined up price column and leader dots, which invite guests to shop by price alone. The dollar sign finding and its limits are set out in references/change-playbook.md.
• Keep one honest premium anchor per section at most, a real dish priced to sell occasionally. Never list a dish you do not intend to sell.

6. Re-measure after one full cycle

• Wait one full period of the same length as the baseline, matched for day of week mix and season as closely as trading allows. Skip or flag weeks with holidays, closures, or one off events in either period.
• Run the comparator: bin/menu_engineering.py before.csv --compare after.csv. It reports weighted average margin, total contribution, and units for each category, plus per item unit, mix, and margin movement and any class change.
• Judge on total contribution and weighted average margin first, item movement second, class labels last. Labels move when thresholds move: removing one item raises the popularity cutoff for every item left, so a Puzzle can gain 17 percent in units and still carry the Puzzle label. The worked example in references/worksheet-and-examples.md shows exactly that.
• Decide per change with the rule written down before the cycle started: keep, extend, or revert. Require a second clean period before calling a change a permanent win, because rename and novelty effects fade.
• Feed the result into the next cycle. Menu engineering is a loop run every period, not a one time cleanup.

Output Contract

Every run delivers: the classification worksheet per category with units, mix percent, price, plate cost, contribution margin, total contribution, class, and the price to reach average margin, with the category popularity cutoff and weighted average margin stated; a borderline and labour flag list; a change list grouped by class where each entry names the item, the single lever being changed, the old and new value, and the review date; and, after a cycle, the before and after comparison with a keep, extend, or revert decision per change. All money figures state the currency of the input data and the period covered. Estimates and stale costs are labelled where they were used.

Operating Rules

1. Every number comes from the point of sale report or a current recipe costing the user can point to. No invented sales figures, costs, or benchmark percents presented as fact.
2. Classify in dollars of contribution margin. Food cost percent is context on the worksheet and never the deciding metric.
3. Classify inside categories only, over a stated period, with disruptions in that period written on the worksheet.
4. One change lever per item per cycle, logged with old and new values, so the re-measurement can attribute the result.
5. Never recommend cutting the only dietary or kids option in a category, or discounting a Star, without flagging the trade off in plain words next to the recommendation.
6. Treat published menu psychology effects as leads to test in the user's own room, not as guaranteed lifts. Report what the user's own before and after data shows.
7. Style: plain and direct language, no em dashes, no marketing phrasing anywhere in output.