Running multiple locations without multiplying the admin
Each new location shouldn't mean repeating all the admin. But that's what happens when sites run on separate tools. Here's how to add locations without adding overhead.
The short answer: opening a new location shouldn't mean repeating all your admin — but it does when each site runs on its own tools and spreadsheets. The fix is a shared system where setup, reporting and management happen once and apply across every site, so admin grows far slower than your footprint.
For a lot of growing groups, this is the quiet killer. Revenue scales with locations, but so does the back office — and eventually the admin eats the margin the new site was supposed to add. It doesn't have to be that way. The relationship between "number of sites" and "amount of admin" is a choice you make in how you set your systems up.
The short version
- Separate systems per site mean admin repeated per site.
- Shared systems let you set up and manage once, across all locations.
- Local differences (pricing, staff, stock) can still vary where needed.
- Admin then grows far slower than the number of sites.
Why does admin multiply?
When each location has its own account, spreadsheet or tool, everything is done per site. Set up a new service? Do it five times. Pull the numbers? Reconcile five sources. Change a price? Update it everywhere by hand. The admin scales linearly with locations — every new site adds a full copy of the back-office work — so growth feels like drowning rather than winning.
The worst part is how invisible it is. No single task feels unreasonable; it's the repetition that gets you. Updating one price is a two-minute job. Updating it across nine sites, checking each one saved, and fixing the one that didn't is an afternoon. Multiply that across every routine change and you've hired people just to keep separate systems in sync.
How does a shared system stop it?
A single system built around how your group works breaks the link between sites and admin:
- Set up once — configure a service, a rule or a template centrally and it applies everywhere, immediately.
- Report once — one view across the group, no per-site reconciliation and no stale exports.
- Manage once — changes roll out to all sites at the same time, not one login at a time.
- Onboard new sites onto the rails — a new location joins the existing system rather than starting from a blank page, so opening site ten is far less work than opening site two was.
The effect is that admin stops tracking your footprint. You can double the number of locations without doubling the back office, because the work that used to repeat now happens in one place.
Can locations still be different?
Yes — and this is the part people worry about. Sharing a system doesn't mean forcing every site to be identical. A good multi-site setup lets each location keep its own pricing, staff, stock and schedule where those genuinely differ, while sharing the source of truth and the oversight. Central where it should be, local where it needs to be.
That balance is what makes consolidation stick. If a shared system flattens real differences, people revert to spreadsheets to handle them and you're back where you started. Done properly, you get consistency where it counts and flexibility where it matters. We cover this in Setting different prices, staff and stock per location.
What's the compounding win?
Because admin no longer multiplies per site, the marginal cost of each new location drops. That changes the economics of growth: you can expand without the back-office growing in lock-step, which is often what makes further growth viable at all.
It compounds in the other direction too. Every process you centralise once keeps paying off at every site, forever. Every report that assembles itself saves that time every single week. A group of ten sites running lean back-office isn't ten times the admin of one — with the right system it can be a fraction more than running one site well. That's the standing saving that funds the next stage of growth, and it's closely tied to why software should get easier as you grow, not harder.
What does this look like day to day?
Picture a services group with six locations. Before: each site keeps its own bookings spreadsheet, its own price list, and its own end-of-week tally that head office chases every Monday. A price change means six emails and six follow-ups. A new service means six separate setups and inevitable inconsistencies.
After: one system holds every site. A price change is made once, with each location free to set its own rate where that's genuinely different. Bookings and results roll up automatically, so Monday's group picture is already there — no chasing. Adding a seventh location is mostly flipping it on and setting its local details. The owner's week shifts from reconciling to actually managing.
Related reading
- Up to the pillar: Scaling operations: systems that grow with your business
- Group oversight: seeing every location at a glance
- Setting different prices, staff and stock per location
The honest first step
Cutting multi-site admin starts with seeing where the same work is repeated across your locations today. Mapping it shows what should be centralised and what should stay local — and how much admin a shared system would remove. That diagnosis is where the value is; the build follows from what it finds.
Tell us what you run, and we'll show you what's possible.
