Running more than one location — venue groups, master recipes, and shared identity
The rule: things that define the brand live at the group. Things that happen on the floor live at the venue.
You opened io osteria centrale three years ago. Now you’re opening io osteria nord across town. Same brand, same chef, same menu — but nord has a different rent, a different team, different opening hours, and (probably) a slightly different supplier mix because the cheese guy near nord won’t deliver to centrale.
The system models this with a venue group. A group sits above your venues. You attach venues to it. The group owns the things that should be the same across every location: the recipe library, the menu items, the inventory item identities (what counts as “burrata” vs “mozzarella di bufala”), the supplier identities, the category structure, the role catalog. Each venue keeps the things that are genuinely local: prices, stock counts, on-time delivery history with each supplier, today’s orders, the staff roster, the tax-invoice numbers.
What it does
Three layers of sharing, applied per kind of thing:
| What | Where it lives | What each venue keeps |
|---|---|---|
| Recipe master (ingredients, method, yield) | Group | Local cost (rolled up from each location’s ingredient prices) |
| Menu item master (name, description, photo) | Group | Local price, availability flag for today |
| Inventory item identity (“Burrata”) | Group | Local stock level, par level, storage location |
| Supplier identity (name, contact, payment terms) | Group | Local pricing, lead time, PO history, on-time % |
| Category structure (recipe / menu / inventory) | Group | Optional per-venue label or order override |
| Role catalog (head chef, line cook, waiter) | Group | Optional per-venue capability tweaks |
Plus a few things that are always per-venue: orders, the till, the prep board, today’s stock counts, the kitchen display, the staff roster, the address, the tax invoice numbers.
How to use it
Adding your second location
- The platform team registers the venue group and lifts your existing venue into it. Your day-to-day doesn’t change — the menus, suppliers, recipes you’ve built up are now master rows at the group level, with your venue inheriting them.
- The platform team creates the second venue under the group. Every master gets a fresh local instance at the new venue automatically — same recipes, same menu, same supplier list, ready to use.
- You enter the new venue’s address, hours, opening date. You set local prices (which may match centrale’s or differ — for instance, nord is in a touristier area, your spritz is €1 higher). You log stock as it arrives.
- Open day: you serve.
You did not type the menu twice. You did not re-create the supplier list. You did not re-define the prep recipes. The shared part flowed across; the local part is yours to set.
Sync vs diverge
For everything at the group level, each venue’s local copy starts synced — when the group master changes, your venue’s copy follows. If you want to override a field locally (nord uses a slightly different burrata supplier, or the carbonara at nord uses a different pepper), you diverge that field. The system shows you a badge next to the row: synced (gray), diverged (orange), or conflict (red — meaning the master changed since you diverged, and you may want to merge).
Two actions on every divergence:
- Pull latest from group — overwrite your local value with the master’s current value. Use when you decide your override isn’t worth maintaining.
- Push to group — overwrite the master with your local value, so every other venue inherits it next. Use when your local improvement should become the brand standard.
The system never silently overwrites. Both actions show you a diff before you confirm.
Across-venue stock movement
When centrale’s kitchen prepares a big batch of pizza dough and ships half to nord, the system models that as an inter-venue transfer. The head chef at centrale declares “5kg of this dough → nord” before they start the batch. When the prep batch completes, the source stock automatically decrements and the transfer is marked shipped. The staff at nord taps “receive” and the destination stock is credited.
If both locations belong to the same legal entity, the transfer is an internal stock reclassification — no VAT, no invoice. If the two locations belong to different legal entities, the transfer is recorded and the operator issues an invoice manually via the existing tax-invoice flow. (Auto-invoicing across two companies is a future feature.)
See [[inter-venue-stock]].
Telegram alerts
If you’re paired with the bot at one location, you see that location’s alerts (low stock, prep delay). If you pair at the group level, you see alerts from every member venue, each one prefixed with the venue name so you can tell centrale’s burrata is running low vs nord’s. The pairing at group level happens once and covers current AND future locations — opening a third venue doesn’t require a third pairing.
Try this on your own data
- Open Settings → Group in the admin app (visible only when your venue belongs to a group).
- Walk through the master recipes. Note that costs are recomputed per venue from the local inventory.
- On a recipe, change a field — pick something benign like a step description. Click Push to group. See every other venue update.
- On another recipe at a different venue, override the price. The badge flips to “Diverged”.
- Try the transfer flow — declare a small batch transfer to a sister venue, run the prep, and confirm it arrived.