Insights

Menu engineering: which dishes are paying the wages?

Ask a chef which dish is the winner and you will hear the best seller. Ask the owner and you will hear the priciest plate. Neither answer is the one that pays the wages. What pays the wages is cash margin per portion, multiplied by portions sold — and most kitchens work that out once a year, on a spreadsheet, at prices that were true in January. Here is why, and what changes when the calculation is a screen.

The pain: menus judged on the wrong number

The best seller may be feeding the guests and starving the business. A dish that sells three hundred portions a month at a margin of forty is the backbone of the outlet — until its main ingredient goes up by a third and the margin quietly halves. It still sells three hundred. Nobody notices, because nobody is looking at margin per portion, only at the sales report.

The profitable dish may be hiding at the bottom of page two. A plate with a handsome margin that sells four times a week is usually not a kitchen failure but a menu one: a poor name, a bad position, servers who never suggest it. It gets cut at the next revision because "it doesn't sell".

And re-costing happens when the menu is reprinted. Recipe in a binder, prices in the storeroom, sales in the POS: somebody has to bring all three to one desk, so it happens twice a year at best, and every decision in between is made on last season's numbers.

Why it happens: the two halves live in different systems

Menu engineering is not new; the matrix that crosses how often a dish sells with how much it earns per portion has been taught for forty years. It stays a classroom exercise for a structural reason: the sales half and the cost half live in different products from different vendors.

• The POS knows what sold, at what price, in which outlet — but has no idea what it cost to make.
• The storeroom knows what every ingredient cost on the last delivery — but has no idea which dishes use it.
• The recipe joins the two — and lives in a binder or a spreadsheet nobody updates when the supplier changes the price.

So the join is a person, and a person does it when there is time, which is when the menu is being redesigned anyway. The multi-system tax, this time paid in the kitchen.

How WinX fixes it: sales, recipe and purchase price on one database

In WinX the three halves were never apart. The POS outlets, the recipe builder and purchasing are modules on the same database, so the menu engineering screen is a query, not a project:

• Sales come from the POS — portions and revenue per dish, per outlet, on the same revenue dates the F&B reports use, so the screen and the reports agree. An item given away at zero price is not counted as a sale.
• Cost comes from the recipe — the recipe and its sub-recipes, priced at each ingredient's last purchase price from purchasing. It is the same costing the Menu Per Outlet screen uses, so the chef, the F&B manager and the accountant read one number. The same recipe that knocks stock off at every sale.
• Every dish gets a name and an action — Star, Plowhorse, Puzzle or Dog, against two lines drawn from your own menu: a dish sells well at 70% of an equal share of the portions, and earns well at or above the menu's average margin per portion. Filter to one outlet or one menu category and the lines move with it, because a dish is a star relative to the menu it is actually on.
• Any period, any browser — this month, last month, or the week of the food festival, opened on the tablet the F&B manager already carries. WinX is thick server, thin client: nothing is installed at the outlet and nothing needs updating when the screen improves. The same live-ledger logic that puts the P&L on the day.

How it reaches the bottom line

The matrix pays without a single extra cover. A plowhorse that sells 300 portions a month at a margin of 40 returns 12,000. Re-cost the recipe and lift the price by 8, and the same 300 portions return 14,400 — 2,400 a month from one dish, with no new equipment and no new guests. Every portion a server moves from a plowhorse to a puzzle earns the difference between the two margins, and every dog removed is less waste, less prep and less stock tied up. The report's job is to tell you which three dishes to spend Monday morning on.

Proven where the outlets are many

Recipe costing on the POS database is not a bolt-on in WinX; it is how the F&B module has always worked. Manila Ocean Park + Hotel H2O run around 40 outlets on one installation, every one selling from recipes costed off the same purchasing records the storeroom receives against; Cebu Ocean Park runs its F&B the same way. Menu Engineering reads those records as they already are — nothing new to set up, beyond costing the recipes not yet costed.

Common questions

What is menu engineering?

Every dish placed on a two-by-two matrix: how often it sells against the cash margin it earns per portion. Sells and earns well is a Star; sells well but earns little is a Plowhorse; earns well but sells little is a Puzzle; neither is a Dog. Each name comes with an action — protect, re-cost, promote, or remove.

Why do most restaurants only do it once a year?

Because the two halves live in different places. The POS knows what sold, the storeroom knows what ingredients cost this month, and the recipe is in a binder. Joining them is a manual job, so it happens when the menu is reprinted, on prices that were true when the spreadsheet was last opened.

Where does the dish cost come from in WinX?

From the recipe and its sub-recipes, priced at each ingredient's last purchase price from purchasing — the same costing the Menu Per Outlet screen uses. A dish whose recipe has no ingredients has no cost, so it is named Not costed and left out of the matrix and the averages rather than shown as pure profit.

Does it need anything installed at the outlet?

No. WinX is thick server, thin client: the report runs on the server and opens in any browser, on the tablet or laptop the F&B manager already carries. Nothing to install, nothing to update when the screen improves.

Related: Purchasing: why the storeroom runs out on Saturday night · WinX POS · P&L on the day, not at month-end · One bill across hotel, park, F&B and spa · Case studies