Make every sale aprofitable sale

Managing restaurant sales is not the same as tracking revenue

Three symptoms of steering by revenue

• Food cost is discovered at month end — the ratio lands with the accounts, four to six weeks after the service it describes. Too late to act on a menu, a portion or a supplier; you record instead of correcting.
• Nobody knows which dishes are profitable — best-sellers are known by volume, never by margin. Yet a high-volume low-margin dish and a low-volume high-margin dish call for opposite decisions.
• Stock variances cannot be explained — the count never matches, and without a theoretical consumption derived from sales there is no way to tell a keying error from real loss, theft or over-portioning.

A service can break a revenue record and destroy margin at the same time. It is in fact the most common scenario: the dishes that sell fastest are rarely the most profitable, and rising revenue hides a drifting food cost effortlessly. As long as sales live in the POS and costs live in a spreadsheet, nobody in the business can say which plate actually made money last night.

Managing sales therefore means connecting three things most tools keep apart: what was sold, what it cost to produce, and what left the stock to produce it. Until those three meet inside the same system, you are steering by revenue — which means steering blind on margin.

That is what this module is for: Melba's sales management starts at the POS line and walks back to the recipe used to produce the dish, through the stock it consumed.

Connecting the POS: what it actually changes

What the connection automates

Setting up the connection, in the right order

• Stock deduction — every sale decrements the ingredients of its recipe. Theoretical stock updates continuously, with no data entry.
• Real food cost — ingredient costs follow supplier prices in force at the time of the sale, not an average frozen in last year's spreadsheet.
• Theoretical versus actual reconciliation — the gap between what sales should have consumed and what the count finds becomes a usable indicator, service after service.
• Replenishment triggers — sales feed forecasts, which feed supplier orders. You order on observed consumption rather than intuition.
• 1. Get the recipes right for your best sellers — twenty to thirty references usually cover most of the volume. There is no point aiming for completeness before you have one usable figure.
• 2. Align the POS catalogue with those recipes — one POS item must point at exactly one recipe. Duplicate labels, catch-all "miscellaneous" items and undecomposed set menus are what break matching in practice.
• 3. Connect and let it run for a week — the first week is for spotting unmatched items and absurd variances, not for drawing conclusions about margin.
• 4. Take a baseline stock count — it sets the starting point for theoretical stock. Without it, the variances computed afterwards mostly measure how wrong the starting point was.

The POS connection is the starting point. Melba pulls the tickets, matches them against recipes, and deducts from stock what production actually consumed. Matching happens at the sold-item level, not on an end-of-day total — that granularity is what makes per-dish margin computable.

Available connectors cover the most widespread systems in France and internationally. The principle is the same for all of them: the POS stays in charge of taking payment, Melba takes charge of the analysis. See the list of connectable POS systems.

For caterers and event catering the entry point is the quote, not the POS. A customer request becomes a forecast sale, then a scheduled production task, then a confirmed sale — the same chain, taken further upstream.

The classic mistake is wiring up the POS before recipes are reliable. Sales then come through correctly but attach to nothing: no food cost can be computed, and stock variance becomes unreadable. The order that works is the opposite one.

From there the numbers become usable with no extra work: every service feeds margin, theoretical stock and purchasing requirements.

Working out real margin, dish by dish

The four numbers that matter

The weekly routine that makes these numbers useful

• An up-to-date cost price — recalculated whenever a supplier price or a recipe changes, using real ingredient yield rather than gross weight.
• Food cost ratio per dish — cost against net selling price. This is what tells you whether a dish absorbs a supplier increase or whether the portion, the price or the recipe has to change.
• Gross margin in currency — a flattering ratio on a cheap dish earns less than an average ratio on a high-ticket one. The percentage on its own misleads regularly.
• Contribution to the bottom line — unit margin times volume sold. It is the only figure that ranks a menu correctly, and it necessarily crosses sales with costs.
• The five highest-contribution dishes — are they visible on the menu, suggested by the floor team, available? High contribution on a hard-to-find dish is margin left on the floor.
• Dishes whose food cost ratio moved — a swing of more than two points week on week almost always comes from a supplier price or a portion change. Both are fixable, if seen within the week.
• The three largest stock variances — by value, not by quantity. Ten kilos of flour matters less than two kilos of scallops, and it is the second one you explain first.
• The comp and waste rate — when it climbs without explanation it usually points at a production or forecasting problem rather than a commercial one.

A dish's margin is not its selling price minus its theoretical food cost. In between sit real yield after trimming and cooking, waste, comps, supplier price moves and portions that drift from the recipe. A cost worked out once at opening is wrong six months later.

Crossing those four numbers is what menu engineering means: ranking dishes by popularity and profitability to decide which to promote, rework, reprice or retire.

Across several sites the exercise changes scale: the same recipe produced in two locations does not cost the same when purchase prices differ. Consolidation by site then by group is covered in the multi-site ERP module.

A dashboard nobody opens is worthless. What separates the businesses that hold their margin is not the sophistication of the tool but the regularity of the reading. Thirty minutes a week is enough, provided you always look at the same things.

All four readings come from data the POS connection produces automatically. No extra entry is required — which is exactly the point of tying sales to the rest of operations instead of analysing them separately.

Frequently asked questions about sales management

Do we have to change POS to use Melba?

How often do sales come through?

How are comps, discounts and waste handled?

What about a caterer with no POS?

Is sales data used for anything else?

How long before the numbers are trustworthy?

What happens when a recipe changes mid-month?

Can several sites with different menus be tracked together?

No. Melba connects to the POS already in place and does not touch payment. The point is to exploit sales data, not to replace the tool producing it. Where a POS cannot be connected, importing a sales file still works.

Continuously for POS systems connected by API: the service's sales are usable as soon as the service ends. For file imports, the frequency is that of the drop, usually daily.

They are kept apart from real sales and tracked separately. This matters: a comped dish consumes stock without generating revenue, and folding it into sales would distort both margin and stock variance.

The flow starts at the quote. Each quote line is a forecast sale feeding production and purchasing, then confirmed as a real sale. Businesses without a POS — caterers, central kitchens, contract catering — use this path.

Yes: it feeds production forecasts, purchasing requirements and traceability. A sale tied to a production batch lets you walk the chain back during a food-safety inspection — see hygiene and traceability management.

Allow one week of sales to catch badly matched items, and one full stock cycle before variances become interpretable. Per-dish margins, on the other hand, are correct as soon as recipes and supplier prices are — often before the first sales even come through.

Cost prices are historised: earlier sales keep the cost in force when they happened, later ones take the new one. That is what lets you compare two periods without a recipe edit rewriting the past.

Yes. Each site keeps its own menu, purchase prices and POS; consolidation happens at group level on the comparable indicators — food cost ratio, contribution, variances. This is the main use case for chains and restaurant groups.