Your central kitchen is a supplier. Treat it as one.
A central kitchen supplying 10, 30 or 100 destinations can only be controlled if it sells to each one as any other supplier would, in the format they order in and at the right price. We build that relationship: its offer, its internal customers and the checks that what’s sent matches what’s received.
Sound familiar?
- 01
"The central kitchen produces and sites receive, but nobody knows at what cost."
- 02
"We send trays and the site counts kilos."
- 03
"What leaves the central kitchen doesn’t match what arrives at the sites."
- 04
"Sites buy elsewhere what the central kitchen already produces."
What makes your operation complex
Two catalogues in one: what the central kitchen buys and what it sells.
Dispatch formats different from purchase formats.
Internal destinations and, sometimes, external customers using the same production.
A cost per unit produced that almost nobody knows.
What we build
The central kitchen’s catalogue: what it buys and produces, with units and dispatch formats.
The central kitchen’s preparations costed, with yields.
The central kitchen as an internal supplier to each destination: its offer in the minimum sales format and each destination as a customer in central store mode.
Each destination ordering from the central kitchen as from a supplier, with its stores and POS.
Checks that what the central kitchen sells matches what each destination receives.
What your team runs
The central kitchen produces, fulfils orders and records waste. Destinations order, receive and run stock counts. Management sees cost by destination.
If you already use tSpoonLab
The most common thing in central kitchens is a flow built with transfers, which move stock but not cost, instead of an internal supplier, or an offer in the wrong format. We fix it and reconcile the history from the last stock count.
See account clean-up