Optimize restaurant & food service operations with smart ERP

Any food business past two locations ends up producing centrally, and that is the point where ordinary retail stock control stops working. A branch that receives trays of prepared food has not made a purchase. It has received a transfer, and if the system records it as a purchase then group food cost is counted twice.

Treating the central kitchen as a production unit rather than a warehouse also settles an argument that runs in every restaurant group. When margins slip, the branches blame the kitchen and the kitchen blames the branches. With production cost calculated at the kitchen and consumption tracked at the outlet, the answer sits in one report instead of in a meeting.

Yield is where kitchen theory and kitchen reality separate. Twenty kilos of beef does not become twenty kilos of portions. It becomes trim, bone, cooking loss and whatever was cut badly, and the recipe card that assumes otherwise understates your food cost on every plate.

Recording input against output on each production run makes the loss a number. Over a few months, yield per item is one of the few genuinely useful pieces of information a restaurant group can have, because it says where the money is going before anybody has to accuse anyone of anything.

Sub-recipes work the same way. A sauce produced centrally has its own cost per litre, and when the price of an ingredient in it moves, the cost moves in every dish that uses it rather than in the one somebody remembered to re-cost.

Food purchasing has a specific weakness that other industries do not share. Deliveries arrive daily, often before opening, and are received by whoever is there. Short weights, substituted items and prices that differ from the agreed list get accepted because the kitchen needs the goods and the argument is not worth having at six in the morning.

Matching the delivery against the order does not remove that pressure. It records it, which means the pattern becomes visible at the end of the month rather than staying an individual annoyance.

Most restaurant groups know their waste figure and cannot break it down, so the response is a general instruction to be careful. That never works, because the three causes have nothing to do with each other. Over-ordering is a purchasing decision, yield is a technique problem, and expiry is a rotation problem.

Perishable ordering in particular improves quickly once consumption per outlet is visible. A branch ordering to a fixed weekly pattern regardless of last week's sales is a common and expensive habit, and it usually survives because nobody has ever put the two figures side by side.

The honest position here is that Wizard is not a delivery aggregator integration. It will not pull orders out of the platforms on its own, and what is possible depends on what each platform exposes. Some groups feed the data in from their POS, some import a daily summary, and that is a scoping conversation rather than a checkbox.

What is worth doing regardless is separating the revenue and its costs. Packaging is a real cost that only applies to delivery. Commission is a real deduction. A dish that carries a fair margin on a table can be close to break even through a platform, and a restaurant that cannot see that keeps pushing volume through the channel that pays it least.

A branch doing high revenue can be the least profitable one in the group, and in a business where food and labour together take most of the revenue, two or three points of difference between outlets is the whole operating profit.

One dependency worth understanding before you start. Cost analysis at this level needs item level sales data, and that comes from your POS. If the POS reports daily totals rather than what was actually sold, consumption against sales cannot be calculated and you are left with stock counts alone. It is a solvable problem, but it is better solved during implementation than discovered afterwards.