Menu engineering for hotel restaurants: the four groups and how to use them

Menu engineering is a method that sorts every dish on a menu into four groups using two measures: how many guests order it, and how much each sale contributes after food cost. The groups are stars, plowhorses, puzzles and dogs, and each one calls for a different decision about price, portion, placement or removal.

The menu has not changed in three seasons, and nobody in the building can say which dish pays for the kitchen. The till already holds the answer: one month of item counts, set against the cost of each plate. After reading this you will be able to run the calculation yourself, sort your dishes into the four groups, and leave the meeting with one written decision per dish.

What does menu engineering actually answer?#

It answers one question per dish: does this item earn its place on the menu, and if not, what exactly should change? Treat the menu as a portfolio. Every dish competes for the same guest, the same grill and the same twenty minutes of kitchen time at peak, so the question is not whether a dish is good but whether it deserves its slot.

The method uses two measures, not one. Popularity is the share of all items sold that this dish accounts for, usually called menu mix. Money is the contribution margin per plate: the price the guest pays minus the food cost of that portion.

Food cost percentage alone misleads. For example, a soup costing 30 percent of a low price and a steak costing 30 percent of a high price look identical as percentages and leave very different amounts of money on the table. Menu engineering exists partly because the percentage hides exactly the difference that matters.

Be clear about what the method does not do. It does not price a new dish, judge service quality, or tell you whether the restaurant concept is right. It sorts what you already sell and prescribes an action for each item. Menu mix analysis on its own is only the popularity half of the method: a mix report tells you what guests choose, and menu engineering adds what each choice earns.

The output is a sorted list plus one written decision per dish, not a score or a ranking for its own sake.

What data do you need before you start?#

Two datasets: how many of each dish were sold in a defined period, and what one portion of each dish costs in food. Sales counts per item come from the point of sale system over a closed period, normally one full month, or the whole season if the menu is seasonal. A partial week flatters whatever the weekend guests order.

Decide up front how to treat staff meals, complimentary dishes and items served from a buffet line. Either exclude them or count them in a separate column, but do not mix them into guest demand.

Portion cost comes from a standard recipe: every ingredient, its usable yield after trimming, and its unit cost at the most recent purchase price. Without a recipe you have an estimate, not a cost. Our guide to standard recipes and portion cost for hotel kitchens covers how to build one.

Three more rules keep the data honest:

• Use the price the guest is actually charged, after any discount that applies to everyone, and keep the tax treatment identical across every dish. Ask your accountant which figure to use so the comparison stays consistent.
• The period and the recipe must match. If a recipe or a portion changed mid-month, either cost the version that sold most or split the period in two.
• Run four hygiene checks before calculating: dishes with zero sales, dishes created in the system but never served, modifiers that change cost such as extra cheese or a second side, and plates designed for sharing.

If there is no point of sale system, a tally sheet at the pass for four weeks works. The counts matter more than the tool.

How do you calculate the menu engineering matrix?#

For each dish, divide its units sold by total units sold to get menu mix, subtract food cost from price to get contribution margin, then compare both numbers with the menu's averages. Work through it in five steps.

Step one: add up the units sold across all dishes in the period. That total is the denominator for every mix figure. Step two: divide each dish's units by that total to get its menu mix as a percentage. Step three: subtract the portion cost from the selling price to get the contribution margin per plate. Step four: multiply the margin by the units sold. This shows which dishes carry the menu in money, which is often not the same list as the highest-margin dishes. Step five: set two thresholds.

Popularity is usually 100 divided by the number of dishes, so six dishes give 16.7 percent each. The money threshold is total contribution divided by total units, the average margin per plate actually sold. Pick one threshold method and keep it. Equal share is simple and easy to explain to a kitchen team; a weighted average is fairer when prices vary widely. Switching methods between quarters makes the comparison meaningless.

A dish above both thresholds is a star, above popularity only a plowhorse, above margin only a puzzle, and below both a dog.

For example: a six-dish à la carte menu over one month (illustrative figures, not a real hotel).

The totals: 1,185 units, average contribution 202 TL per plate, total contribution 239,950 TL. The two thresholds used are 16.7 percent menu mix and 202 TL average contribution. Notice what the table already shows: the chicken skewer, not the ribeye, carries the most money, because volume multiplies a modest margin.

What do the four groups mean and what should you do with each?#

Stars sell above average and earn above average, plowhorses sell above average but earn below, puzzles earn above average but sell below, and dogs are below on both. Each group has its own first move.

Star: protect it. Keep the recipe and the position on the page, resist the urge to discount it, and check that the kitchen can plate it at peak. A modest price test is reasonable only with a stated reason.

Plowhorse: fix the cost, not the demand. The guest already likes it, so the money is in the cost or the portion, not in the price. Re-specify the recipe, renegotiate the supplier, change the garnish, or raise the price in small steps. Removing a popular dish is usually the wrong first move.

Puzzle: fix visibility before price. The dish earns well but is not chosen. Look at where it sits on the page, how it is described, and whether the waiting staff mention it. Give it a full quarter of visibility before deciding.

Dog: remove it, re-engineer it, or keep it deliberately. Legitimate reasons to keep one include a children's dish, a dietary requirement, a dish the hotel's identity depends on, or a supplier contract that makes removal costly.

Two cautions. A dish sitting exactly on a threshold is not a verdict; treat the matrix as a sorting tool and re-run it before acting on a marginal case. And the matrix says nothing about kitchen labor, equipment time or waste. A profitable dish that blocks the grill at 20:30 is a different problem with a different answer.

How do you change the menu without misleading guests?#

Change what the guest can see and choose, not what the dish actually is: position, name, description and the staff suggestion are honest levers, and a description that overstates the plate is not.

Placement is free. Menu convention puts the first items in a category and the top and bottom of a page where guests look first; treat it as a convention, not a measured rule. Moving a puzzle there costs nothing and changes nothing about the food. Descriptions should say what is in the plate and how it is cooked. Do not invent provenance, a family recipe, or a health benefit the kitchen cannot stand behind.

Keep prices in one plain column without decorative repetition of the currency, so guests compare dishes rather than prices. This is common practice, not a rule, and it should never be used to hide a price. The strongest lever is a person: brief the waiting staff with one sentence per puzzle dish and let them recommend it. A suggestion from staff usually does more work than any typographic trick, and it costs nothing to test.

Allergen and dietary information should be updated the same day as the recipe, and the hotel should confirm its own legal obligations with its adviser. A menu that is right in the kitchen and wrong on the page is a trust problem, so treat the update as part of the recipe change, not an afterthought. A portion change is a recipe change: it belongs in the standard recipe first, and the description should follow it, never the other way round. Raise prices in one deliberate step with a reason the guest can see, such as a new supplier or a larger portion, rather than across the whole menu at once.

Does menu engineering work in an all-inclusive hotel?#

Yes, but the popularity axis changes meaning: in an all-inclusive hotel a dish sold is a dish consumed, not revenue collected. The guest has already paid, so the count per dish measures demand and kitchen load rather than sales income. Keep the counts, change the second measure.

Use cost per portion, or cost per cover, where an à la carte restaurant would use contribution margin. High consumption combined with high cost is the group that needs attention first. On a buffet, count what leaves the line rather than what the till records: production against consumption, plus what is weighed as waste at the end of service. The same logic sorts dishes by demand and cost.

In an à la carte restaurant inside an all-inclusive hotel, booking rules and no-shows distort the counts. A dish ordered by few guests may reflect table availability rather than preference, so read the numbers next to the reservation pattern. Our piece on à la carte restaurants in all-inclusive hotels and booking rules guests find fair goes into that setup.

The levers are smaller. You cannot raise the price of an included dish, so the tools are portion, recipe, how often the dish appears on the rotation, and where it sits on the page. Watch one trap: cutting cost per cover can produce complaints that cost more than the saving. Read guest comments alongside the matrix, not after it.

How often should you run it, and what changes?#

Run it once a quarter on a full month of data, and again after any menu change, price change or significant supplier change. Quarterly matches seasonal menus and the pace at which supplier prices move. Monthly runs on a small menu are mostly noise.

Keep a one-page record per run: date, period, the two thresholds used, each dish's group, the action taken and the next review date. Without it, next quarter's numbers cannot be compared with this quarter's. Compare groups across runs, not only within one. A puzzle that stayed a puzzle for two quarters is a decision the hotel has made, whether or not anyone wrote it down.

Run it alongside the cost controller's cycle so the recipe costs and the sales counts come from the same period and the same definitions. Our guides to food and beverage cost control in hotels and what a hotel cost controller does each day cover that rhythm.

Expect the matrix to tell you where to look, not what will happen. No method can promise a profit increase, and any supplier or consultant who does should be asked for the working. The first run is the expensive one, because the recipes may not exist yet. Build them once and every later run is a few hours of arithmetic.

What to do next#

Pull one month of item counts and cost the dishes that appear on them, then run the matrix once and write one action per dish with an owner and a review date. The four groups are only a sorting tool. The value comes from the written decisions that follow, and from running the same calculation again next quarter so the comparison means something.