One site is a rota. Two sites is two rotas. Somewhere around the third or fourth, the work stops scaling linearly and starts scaling badly, and the reason is almost never the scheduling itself.
It is that nobody ever decided where decisions get made.
The question underneath all the others
For every scheduling decision there is exactly one good answer to "who decides this", and the trouble starts when the answer is different depending on who you ask.
Three things are worth being explicit about, because they are the ones that silently get answered twice:
- Who can publish a rota for a site? The site manager, or the centre?
- Who approves a swap that stays inside one site? Almost always the site. Almost always in practice it goes to whoever is fastest to reply.
- Who approves anything that crosses sites? This one has to be the centre, and it is the one most often left implicit.
You can pick either answer for the first two. What you cannot do is leave them undecided, because an undecided question gets decided differently each time, and the cost of that is the double-handling everyone attributes to "having multiple sites".
Staff who work at more than one site
This is where multi-site scheduling actually gets hard, and it is a much smaller group of people than the effort suggests - typically the relief staff, the supervisors and a handful of flexible part-timers.
Three things go wrong with them, all of them invisible from inside a single site's rota:
Double-booking. Two sites both schedule the same person on Saturday, each looking at their own grid. Neither did anything wrong.
Rest periods across sites. Someone closes at site A and opens at site B. Each rota is compliant on its own. The person is not.
Hours totals. Weekly maximums, overtime thresholds and contracted hours are properties of the person, not of the site. Two sites each scheduling 20 hours have jointly scheduled 40, and only one of them will find out.
The fix is not more communication. It is that anyone who works at more than one site needs a view of their own week that crosses sites, and whoever schedules them needs to see the same thing.
What genuinely should stay local
A common overcorrection is to centralise everything, which trades double-handling for a bottleneck and makes the schedule worse - the centre does not know that Tuesday is quiet in one branch and brutal in another.
Local should keep: who works which shift, day-to-day cover, and swaps within the site. The centre should keep: budget, anything crossing sites, and the definitions - what counts as overtime, what the minimum rest is, what a shift template looks like. Definitions belong at the centre precisely so they are the same everywhere; rotas belong locally precisely so they are not.
The reporting trap
Multi-site reporting tends to arrive as a per-site breakdown, which is useful and is not the thing that catches problems.
What catches problems is the comparison. The same metric across sites - labour cost percentage, scheduled versus actual, overtime as a share of hours - is what turns "site four spends a lot" into "site four spends a lot relative to its revenue, and has done for six weeks". A single site's numbers have no baseline. Four sites are each other's baseline, and that is the actual benefit of running more than one.
A short checklist
- Can you name who publishes a rota for each site, without hesitating?
- Do you have a list of people who work at more than one site? If not, start there.
- Can anyone see one person's whole week across sites?
- Are your definitions central and your rotas local, or have those two ended up the wrong way round?
- Do you compare sites, or only report them?