Menu engineering: the matrix, a worked example, and what guests asked for

Menu engineering sorts the dishes in each menu category by two numbers: how many you sell, and how much each one earns after food cost. The two numbers put every dish into one of four groups (stars, plowhorses, puzzles and dogs), and each group gets a different action. The method has one blind spot: it only sees what guests chose from what you offered. Guest questions fill part of that gap. If guests order through a chat, the questions they ask show what they looked for and couldn’t find, and which dishes they didn’t understand. This guide walks through the matrix on an eight-dish menu, then adds the guest-question layer.

What is the menu engineering matrix?

Short answer: a two-by-two grid of popularity against contribution margin, with a standard action for each box.

Two rules keep the matrix honest. Compare dishes only within one category (mains with mains, not mains with desserts), and use the same period for every dish.

How do you calculate it?

Short answer: five columns of arithmetic per dish, then two comparisons.

1. Pick a category and a period. For example, mains over four weeks.
2. Count the number sold of each dish. Use your POS, which has every sale.
3. Work out each dish’s contribution margin: menu price minus plate cost (the food cost of one portion).
4. Work out the totals: total margin per dish (margin × number sold), and the category totals.
5. Set the two lines.
   • Popularity line: an equal share of the category. With 8 dishes, that is 1 ÷ 8 = 12.5% of the dishes sold. Some versions of the method set this line lower than an equal share; pick one rule and keep it.
   • Margin line: the category’s average margin per dish sold, which is total margin ÷ total number sold.
6. Classify. A dish at or above both lines is a star; above popularity only, a plowhorse; above margin only, a puzzle; below both, a dog.

A worked example: Casa Olivo’s mains

Casa Olivo is a fictional restaurant (an example, not a customer). Sales, prices and plate costs are assumptions for the arithmetic.

Four weeks of mains, 1,200 sold in total:

The two lines:

• Popularity line: 12.5% of 1,200 = 150 sold.
• Margin line: $17,180 ÷ 1,200 = $14.32 per dish sold.

The result:

Two notes a careful owner would add. The risotto is a borderline plowhorse: $14 against a $14.32 line, so a small change in plate cost moves it. And the tagine is the only vegetarian main, so dropping it may cost more than its own sales, because a table with one vegetarian guest may go elsewhere. The matrix can’t see that. Guest questions can help.

What should Casa Olivo do with each group?

Short answer: one change per dish, chosen by its group, and nothing at all for the star.

Change one thing per dish, and not every dish at once. If you change the price, the description and the position of a dish in the same month, you won’t know which one worked.

What can guest questions add that sales data can’t?

Short answer: what guests wanted and didn’t find, and which dishes they didn’t understand.

Sales data has a blind spot: a guest who wanted a dish you don’t serve leaves no trace. They order something else, or nothing. When guests order through a chat, they ask, and the questions are data.

WaiterPilot’s owner analytics include top dishes, busy hours, what guests asked for that isn’t on the menu, and questions the chat couldn’t answer, along with today against the same day last week. The owner page has a “Tonight at” summary the owner can send from their own phone by text or WhatsApp. Answers in the chat come from your menu; when the menu doesn’t say, the chat tells the guest to ask a staff member, and that unanswered question shows up in the report.

Back at Casa Olivo, suppose four weeks of reports show this (illustrative figures, not real data):

None of these is a sale. A request shows that someone looked; only a test shows whether they’ll order. Treat the question list as a list of experiments.

What are the limits of the guest-question data?

Short answer: it covers only guests who used the chat, it counts questions not sales, and it can’t see your POS.

• Only chat users. Guests who ordered through a server, or never opened the chat, don’t appear. The reports show what this group asked, not the whole room.
• No POS link. WaiterPilot doesn’t connect to your POS, so its top dishes cover orders placed in WaiterPilot, not orders rung straight into your till. For the matrix itself, use your POS, which has every sale.
• Languages. The chat answers in the guest’s language, and the reports split chats only into Arabic and other languages; there is no full language breakdown.
• Small numbers. A handful of requests in a quiet month is a hint. Wait for a pattern before you change the menu.

What shouldn’t you expect from ordering technology?

Short answer: it won’t fix margins by itself.

Menu engineering works on margin per dish and on which dishes guests choose. Ordering technology doesn’t change those much on its own. The best evidence we have, a peer-reviewed study of tabletop ordering devices across a US casual-dining chain, found about 1% more per check and about 10% shorter meals (Tan and Netessine, Management Science, as reported in 2019). After a guest adds a dish, WaiterPilot may ask once whether they would like anything with it, but we make no claim that it raises check size. Our post on whether tabletop ordering increases check size goes through the evidence.

The value of the questions is the information, not a sales lift: better descriptions, a gap you can test, a dog you understand before you drop it.

Your menu engineering worksheet

Run this each time you change the menu, or once a season:

1. Export four or more weeks of sales by dish from your POS.
2. Update the plate cost of every dish from current supplier prices.
3. Fill in the table: sold, mix, price, plate cost, margin, total margin.
4. Set the popularity line and the margin line for each category.
5. Classify every dish.
6. Read the guest-question report for the same weeks: what was asked for, what couldn’t be answered.
7. For each puzzle, check whether guests asked what it is.
8. For each dog, check whether it serves a group (vegetarian, child, allergy) the matrix can’t see.
9. Pick no more than three changes, one per dish, and write down the date.
10. Re-run the matrix after the next period and compare.

When you change a dish, mark the old version sold out from your phone the day the new one starts, so guests aren’t offered something the kitchen no longer makes. Our checklist for preparing your menu covers how to write the new descriptions, and what to do when a dish sells out mid-service covers the day-to-day side.

What to do next

Export last month’s sales, fill in the table for your mains, and find your puzzles: they are usually the quickest win, because a better description costs nothing. If you use chat ordering, read the questions your guests asked about those dishes before you change anything. To see the owner reports and the rest of the flow, read how it works or check pricing, which is $200 per location per month with the reports included.