Cibuscibus.
Guide · Multi-site

Preparing for multi-location growth.

A second venue needs shared standards, local exceptions, scoped authority and comparable reporting. Build that operating model before the new site opens.

Answer first

The short answer

By Abbas7 min read

Prepare for a second restaurant by separating group standards from site-level decisions. Define a master menu, role and location scopes, a comparable reporting vocabulary, daily operating controls and a rehearsed rollout plan before duplicating technology or data.

  • Create one source of truth for menu structure, allergens and core operating definitions.
  • Grant each person only the site access and sensitive actions their role requires.
  • Run a staged rollout with training, acceptance criteria, incident ownership and a documented fallback.

Multi-location growth introduces decisions that a single venue can keep informal: which data is shared, which settings remain local, who can act across sites and how results are compared. Shared menus, scoped permissions, group reporting and documented operating rhythms make those decisions explicit.

The early signals

Six signs your second site will be painful.

You can't see both kitchens in one place
Switching logins and reconciling separate views adds work before a manager can compare the two venues.
Menu changes drift between sites
A dish, price or allergen update can differ between locations when each site maintains a separate copy.
Permissions are 'trust everyone'
Shared credentials obscure who approved a discount, void, refund or configuration change.
Reports are spreadsheets, glued by hand
When sites define periods, channels and adjustments differently, a combined spreadsheet is difficult to compare or audit.
Hiring restarts from scratch each time
New site, new onboarding pack, new POS training — none of it standardised, all of it dependent on a senior employee.
The founder is the only fallback
Every escalation lands in the same WhatsApp. There is no second line, because nobody else has the access or the visibility.
Framework

A seven-step prep playbook before site 2 opens.

  1. 01Step 01
    Standardise the menu model
    Maintain a master menu with controlled site-level overrides for price, availability and modifiers, so approved changes follow one workflow.
  2. 02Step 02
    Define roles, not people
    Owner, area manager, head chef, shift lead, server, kitchen. Each role gets a permission set. People inherit the role.
  3. 03Step 03
    Scope access by site
    Area managers see their venues. Site managers see their own. Owners see everything. No more 'master PIN'.
  4. 04Step 04
    Set up a group dashboard before site 2
    Agree the group views and definitions for orders, sales, payment methods, shifts, voids and refunds. Make site comparisons use the same reporting period and treatment.
  5. 05Step 05
    Standardise the daily rhythm
    Same opening checklist, same EOD reconciliation, same incident reporting — same time, same format, across every venue.
  6. 06Step 06
    Onboarding pack for staff and stack
    Document how a site is configured, which hardware is approved, how each role signs in, how acceptance is recorded and who owns support escalation.
  7. 07Step 07
    Build a second line
    Train at least one person per venue who can take over when the founder isn't there. Give them the visibility and the permissions to act.
Before / after

What multi-site discipline actually changes.

Two-of-everything
  • Each site is a silo with its own setup and logins
  • Menu changes are copied and checked separately
  • Reports require manual consolidation
  • Voids and discounts drift, no shared baseline
  • Founder is the only escalation point, every shift
One operating layer
  • One operating layer with site-aware overrides
  • Approved menu changes follow one controlled workflow
  • Comparable group and site views
  • Capability-aware permissions and attributed actions
  • Trained second line per venue, with the access to act
Group operations

Six capabilities that make multi-site work.

•
Master menu, local overrides
Items, modifiers, allergens, taxes — defined once. Price, availability and station routing can vary by site without forking the menu.
•
Capability-aware permissions
Define who can discount, void, refund, change a menu or view financial reports, then scope those permissions to the appropriate sites.
•
Group dashboard, by site
Compare agreed operational and payment measures by site without changing definitions between locations.
•
Documented customer-data scope
Define whether customer records and marketing choices apply to one venue, a named group or another legal entity before sharing them across locations.
•
Reach, group-aware
Campaign drafts can target one site, several sites or the whole group. Local managers see only what's theirs; the owner sees everything.
•
Audit trail per action
Confirm which sensitive actions are timestamped and attributed, how long records remain available and who can review them.
Rollout pitfalls

Where multi-site rollouts quietly go wrong.

✓
Don't migrate during peak season
Schedule the rollout to a low-volume window with a real fallback. Weekend evenings are not a test environment.
✓
Don't fork the menu
If site B needs local differences, use controlled overrides where possible. Parallel masters increase the risk of inconsistent items, prices and allergen records.
✓
Don't skip the training day
Train each role on normal work and exception handling, then record acceptance before the cut-over.
Where Cibus fits

How this looks on Cibus.

•
Group and site controls
Cibus supports restaurant and location management, role-aware access and shared operational views within the platform.
•
Admin Dashboard at the group level
Group view, site view, role-aware. Owners see everything; area managers see their portfolio; site managers see their venue.
•
Customer data, governed on platform
Customer and consent records use scoped platform access. The relevant entities must still document controller, processor and marketing responsibilities.
•
Sales Agent Portal for partner growth
If you're growing via area partners or resellers, scoped portfolios, onboarding wizards and commissions are already in the platform.
•
Connected operating surfaces
Cibus connects KDS, Storefront and Rider with the operating platform; the exact site configuration is agreed during rollout.
Connected platform

The surfaces that make group ops feel like one venue.

Admin Dashboard
Group view + site view with role-aware access.
Product
Multi-location management
How shared menus and scoped permissions work in practice.
Platform
Sales Agent Portal
For groups that grow through area partners or resellers.
Product
FAQ

Common questions from multi-site operators.

When should we start preparing for site 2?

Start before committing the rollout plan. Menu governance, roles, reporting definitions, training ownership and fallback procedures should be tested at the first venue before they are needed at the second.

Sources

Primary guidance used in this review

UK National Cyber Security Centre — identity and access management

Primary guidance on binding identities to permissions and applying least privilege.

Food Standards Agency — keeping allergen information accurate

UK guidance recommends controlled records and procedures that keep allergen information current.

UK Information Commissioner's Office — controllers and processors

Guidance for allocating responsibilities when customer data is shared across organisations or suppliers.

This guide is operational guidance. Confirm legal, employment, tax, food-safety and data-protection requirements for every market and entity involved.

Back to all guides

Ready to plan the next site?

See how Cibus connects service, kitchen operations, payments, reporting, customer engagement and delivery into one restaurant operating system.

Book a DemoMulti-location management