The #1 management tool forcentral kitchens

What is a central kitchen? Definition

A central kitchen prepares meals in volume for other sites — satellite canteens, restaurants, points of sale — rather than for diners walking in. Production is concentrated in one facility, then allocated and delivered, which changes everything about how menus, quantities, food safety and costs are managed.

Central kitchen software is first an allocation problem

A central kitchen does not produce dishes: it produces quantities bound for sites with different headcounts, schedules and constraints. The core of the job is not the recipe — it is the chain menu → headcounts → production → allocation → delivery, and that whole chain is what central kitchen software has to hold without re-keying.

Melba starts from headcounts per site and diner category, computes the production plan net of available stock, splits the run into parcels per site with compliant labels, and traces every batch to the serving site. What a central kitchen does daily, in the order it does it.

What breaks when the tool was not built for this

• Allocation in a spreadsheet — splitting one run across fifteen satellites is recomputed by hand at every headcount change. An error only shows at delivery, when a site is served short.
• Re-typed labels — product name, secondary use-by date, allergens, batch number: re-typing these on every dispatch is slow and fallible, when they already exist in the recipe and the production batch.
• Traceability that stops at the dock — knowing what was produced is not enough; in a recall you must know which batch went into which parcel to which site. Without that link, a targeted recall becomes a total one.

Cook-chill and cook-serve, natively

In cook-chill, production runs one to three days ahead: blast chilling recorded, secondary shelf lives computed, finished-goods stock tied to service days. In cook-serve, the plan tracks the day of consumption and the constraint moves to transport temperatures.

Both flows usually coexist in one operation. The tool follows the flow per production run, not per establishment, and each flow's food-safety duties run through the hygiene and traceability module: timestamped readings, retained samples, non-conformities with corrective actions.

A typical day, from menu to delivery round

• D-2 / D-1 — headcounts adjusted by satellites, plan recomputed net of stock, prepared materials issued, production sheets printed per section.
• Day D, production — batch production, chilling recorded, actual quantities captured at validation; the planned-versus-actual gap is visible immediately.
• Day D, allocation and dispatch — split per site, labels generated from batches, delivery notes per round, departure temperatures recorded.
• On return — receipts confirmed by satellites, discrepancies logged, leftovers captured: the loop feeds forecast headcounts and cost per meal.

Pooled purchasing, cost per meal under control

A central kitchen is a de facto purchasing hub: the aggregated volume of all its sites is its negotiating leverage. Purchasing requirements are computed from the consolidated production plan, supplier orders go out once, and per-reference price history turns the annual negotiation into a factual conversation.

The steering indicator is ingredient cost per meal delivered, per site and per menu component, recalculated whenever a price or a recipe moves — which is what lets you hold a contracted cost target without waiting for the accounts. Multi-entity groups consolidate through multi-site management.

Choosing central kitchen software: four criteria that sort quickly

Allocation first: if it happens in an Excel export, everything else will follow the same path. Then traceability down to the serving site, not just to the dock. Compliant labels generated from data, never re-typed. And the ability to run cook-chill and cook-serve side by side without duplicating the reference data — the real case in most operations. A tool that holds these four points will hold the rest.

What volumes can it follow?

The mechanics are the same at a few hundred and at several thousand meals a day: what changes is the number of sites, sections and delivery rounds, not the logic. Scale is carried by batches and parcels, not by faster typing.

Cutting cost per meal without degrading the plate

Durable savings in a central kitchen do not come from shaving portions. They come from three deposits: reasoned substitution — swapping a reference that spiked for an equivalent at the same use, visible because costs are current; seasonality — shifting a recipe a few weeks when market prices allow; and overproduction — the produced-versus-served gap, measured per site, which points at the forecast headcounts to fix. All three require the same thing: fresh data at menu-composition time.

Classic rollout mistakes, and how to avoid them

Deploying everywhere at once — a pilot site settles the reference before widening. Switching recipes without measuring yields — quantities come out wrong and the team loses trust. Keeping the allocation spreadsheet 'as backup' — two truths coexist and the wrong one always wins. And forgetting the satellites: the quality of headcounts entered at the end of the chain makes the quality of the whole production.

Frequently asked questions about central kitchen software

How is this different from catering management software?

The central kitchen is the site that produces; contract catering is the perimeter that consumes. Melba covers both: production and allocation here, cyclic menus and headcounts on the catering side, with sales management where meals are billed.

How do we start without stopping production?

With the recipes behind your highest-volume runs and each site's headcounts, imported from files. For the first weeks the tool runs alongside the existing process on a reduced scope, then the scope widens — never an overnight switch.

Do satellite sites get access?

Yes, with per-site permissions: headcount entry, goods-in on deliveries, local hygiene readings. The central kitchen keeps control of the reference data and the production plan.

Does it handle regulatory approval?

Approval remains the operator's process, but the file rests on evidence the tool already produces: an executed food-safety plan, upstream and downstream traceability, timestamped records exportable over any requested period.

What happens to history when switching tools?

Recipes, menu templates and supplier catalogues come across by import. The old system's production history stays archived: comparisons restart from the first full cycle in the new tool — which is enough, since next season is already being planned on clean data.

Can costs be tracked without changing how the kitchen works?

Yes — the tool observes, it does not dictate. Recipes describe what the kitchen already does, with yields measured on your runs rather than a manual's coefficients. What changes is not the production: it is that every decision — a contract price, a menu, a batch size — finally rests on the real cost of what leaves the dock.

Who typically uses it day to day?

The production manager for planning and allocation, section leads for sheets and validations, goods-in staff for receipts and readings, satellites for headcounts and deliveries, and management for cost per meal. Each role sees its slice — nobody has to learn the whole system.