The short answer
Decide around your actual service
Managing a food court or multi-concept brand requires a clear boundary between shared capabilities and the responsibilities of each stand, brand or kitchen. Model identifiers, routing rules and ownership before consolidating data. An order should remain traceable from its originating channel through preparation and reconciliation, even when it crosses several systems.
Editorial review: · BINOV (opens in a new tab)
Define the operating model before the tools
List the entities that shape the operation: site, concept, stand, kitchen, till, channel and operating company. For each, specify local and central decisions, opening hours, teams and the owner of an incident.
Then identify shared services such as reception, pickup, delivery, purchasing or support. This map prevents a shared tool from hiding a responsibility that still belongs to an individual concept.
Route each order to the right team
Define the rules linking an item to a brand, production point, printer or screen, and then to a handover location. Test single-concept baskets and orders spanning several concepts, including changes and partial cancellations.
Keep an end-to-end identifier and useful timestamps. During a delay or stockout, teams should be able to see where the order is, who is acting and what information is being given to the customer.
Build compatible reference data
Decide which data is shared: item families, tax rates, channels, payment methods, slots and statuses. Preserve stable identifiers for sites, concepts and products so sales can be reconciled without relying only on labels that may change.
Every interface needs a source, owner, frequency and error rule. Rejected or late data should be visible, replayable where possible and handled without creating duplicates.
Consolidate without losing operational detail
Define each metric and its scope: revenue, orders, basket value, preparation time, cancellations and availability. Specify the operating date, refund treatment and analysis level expected by site and concept.
A network dashboard should first reveal a discrepancy and then lead back to its cause. Structure reviews around assigned actions, and monitor data flow quality too: missing records, synchronization delays and manual corrections.
Compare the options
Scroll horizontally to read the full table.
| Decision | Ambiguous model | Manageable model |
|---|---|---|
| Ownership | Site or head office depending on context | Named owner for each process |
| Routing | Depends on channel or manual handling | Rules tested by item and production point |
| Identifiers | Different labels in every tool | Stable keys and documented mappings |
| Metrics | Totals without a shared scope | Shared definitions, cutoffs and treatments |
| Incident | Manual search across systems | End-to-end identifier and visible owner |
Your checklist before choosing
- Map sites, concepts, stands, kitchens and operating companies.
- Assign each process to a central or local owner.
- Test routing for single- and multi-concept baskets.
- Keep a shared identifier through the entire order journey.
- Document reference data, mappings and effective dates.
- Define metrics, scope and daily cutoff time.
- Make rejects and synchronization delays visible.
- Prepare support and fallback procedures by site.
Worth sharing
Could this guide help your team or network?
Send it to the relevant people to support your next decisions.
