01 — Central vs local
Decide what is central and what is local.
The central-vs-local question is the architectural decision behind every multi-site setup. Catalogue, pricing, suppliers, staff structure, reporting — each one has a default home and a set of allowed overrides. Write them down before you launch the second branch.
- Catalogue: usually central, with local availability overrides.
- Pricing: usually central, with local promotion overrides.
- Stock: always local; central views are rollups, not source of truth.
- Reporting: central views built from local data.
Some decisions belong at head office, others belong at the branch. A clean split keeps standards consistent and branch managers fast. Get the split wrong and either head office becomes a bottleneck or branches drift apart.
- Filled cell — this is the decision’s home; the source of truth lives here.
- Soft cell — this side participates but defers to the other for the master record.
- Centralise visibility, not decisions — the goal is shared standards with fast local action.
02 — Central catalogue
Build the catalogue once, deploy it everywhere.
The catalogue is the most-leveraged record in a multi-site operation. Build it once, set the rules for local overrides, and deploy. The alternative — each branch maintaining its own products — turns reporting into archaeology within months.
- Define product, variant, modifier and bundle records centrally.
- Allow local availability flags (this product is sold here, not there).
- Avoid local price overrides except for documented reasons.
- Version catalogue changes so historical orders stay intelligible.
03 — Branch stock
Stock is always local. Visibility is always central.
Each branch knows its own stock. The head office sees all branches at once. The split is important — a centralised stock view that is wrong locally is worse than no view at all.
- Set stock-on-hand at branch level for every product.
- Make branch stock visible across all branches for transfer decisions.
- Surface total stock as a rollup, never as a source of truth.
- Reconcile in-transit stock so it is not double-counted.
04 — Transfers
Transfers are a workflow, not a phone call.
Stock transfers between branches are how multi-site operations balance themselves. A clean transfer workflow — request, approve, dispatch, receive — keeps both branches honest and the central view accurate.
- Build transfer states explicitly: requested, approved, in transit, received.
- Reconcile in-transit stock at both ends.
- Track transfer reason so you can spot patterns (one branch over-orders, another under-orders).
- For high-value items, require sign-off at both ends.
05 — Local pricing & promotions
Allow local control where it matters.
Centralising everything is brittle. Each branch needs the ability to react to local conditions — a competitor opening down the street, a slow-moving line that needs a push, a regional event. The trick is to make local overrides visible centrally, not invisible.
- Define the rules for what local managers can override.
- Make local overrides visible to head office, not hidden.
- Set expiry on local promotions so they do not linger.
- Audit local overrides periodically — patterns reveal a real need or a bad rule.
06 — Staff & sign-in
One identity, multiple branches.
Staff who work at multiple branches should not need multiple logins. One identity, branch-aware sign-in, and consistent reporting across sites means people transferring between sites are not re-learning the system every time.
- Use one staff identity, with branch access flags.
- Track shifts by branch and by staff member.
- Run staff performance reports across branches for fairness.
- Make sign-in fast (PIN or card) so it does not slow service.
07 — Central reporting
Build group dashboards that compare like-for-like.
A group dashboard that just sums all branches together is useful for one conversation — “how big is the business?” For every other conversation, branches need to be compared on like-for-like terms: same opening hours, same week, same product mix.
- Build group rollups for the headline numbers.
- Build comparison views (branch vs branch, week vs week).
- Surface variance from expected — not just absolute numbers.
- Drill from any group number to the underlying branch, order or shift.
08 — Local decisions
Centralise visibility, not decisions.
A branch manager who has to call head office to make a decision is a branch manager who is going to be slow. Centralised visibility is the goal; centralised decisions usually is not. The system should give managers the data, then trust them.
- Define what branch managers can decide locally; document it.
- Surface the data they need (stock, sales, staff) in their own view.
- Make escalation paths explicit — when to involve head office.
- Coach on patterns, not on individual transactions.
09 — Franchise & royalty
For franchise models, build royalty reporting in.
If branches are franchised, royalty reporting is part of the operating model. Build it into the system rather than handing the franchisee a spreadsheet at month-end. Transparent rules make for honest relationships.
- Define the royalty rule (% of sales, fixed fee, both) explicitly.
- Surface royalty totals to the franchisee in their own dashboard.
- Reconcile royalty against actual sales, automatically.
- Provide an audit trail in case of dispute.
10 — Rollout
Open the second branch with the system, not against it.
The hardest branch to open is usually the second one — because that is when the central-vs-local split is tested for the first time. Treat the second branch as a rehearsal for the tenth.
- Document the central catalogue and pricing rules before the second branch goes live.
- Pilot the new branch on a slow day before peak.
- Run group reporting from day one — even if there are only two branches.
- Review the central-vs-local split after one quarter.
SUMMARY
The shape of it.
Multi-site works when the central system gives every branch the same standards and the same visibility, without taking away their ability to react to what is happening on their own floor. Most groups know which decisions belong central and which belong local. The system should make that split easy to enforce, not hard.