Field notes › Rostering
Rostering across multiple client sites without losing the plot
Rostering one client site is a job. Rostering five is a different job wearing the same name. The work does not just multiply, it starts interfering with itself, because the same workers appear on more than one client's roster and the same coordinator is expected to hold all of it in their head. Most labour hire firms hit this wall somewhere between their second and fifth site, usually while telling themselves the spreadsheet is still fine.
The spreadsheet-per-site trap
The natural way to grow is one roster file per client. It feels tidy. Each client has their own tab or their own file, formatted the way that client likes it. The problem is that your workers do not live in one file. A rigger doing days at one site and picking up weekend work at another exists in two files that have never met. Neither file is wrong. Together they are impossible.
Then there is the master copy myth. Someone always claims to maintain the combined view, and it is always slightly out of date, because it is assembled by hand from files that change hourly. The clash you needed to see was in the version from Tuesday.
One timeline across every site
The structural fix is boring and total: every client site on one roster timeline. In Mustr, all sites, day shifts, night shifts, swing patterns and open shifts sit on the same timeline, so a worker's whole week is visible in one place regardless of how many clients it spans.
More usefully, the clash checking is done by the system rather than by whoever happens to be looking. Every booking is checked server-side against the worker's existing bookings across all sites before it lands, and a clash blocks the booking outright. The cross-site double-up, the classic failure of the file-per-client world, stops being something a sharp-eyed coordinator catches and becomes something that cannot be booked at all. The rostering page shows what the timeline looks like in practice.
Every site has its own rules
Multiple sites do not just mean more shifts, they mean more rulebooks. Each site has its own inductions, and clients often require specific competencies for specific roles. A worker who is perfectly qualified for one site can be unqualified for the site next door, and a coordinator juggling five clients cannot reliably hold every combination in memory.
So the same server-side check covers this too. A booking for a worker who lacks the induction or competencies the shift requires is blocked before it exists. And because expiring certificates surface up to 60 days out with one-click reminder emails, the qualified pool for each site shrinks slowly and visibly rather than suddenly and silently. The details are on the compliance page.
Give each client its own window
The other cost of multi-site rostering is communication. Five clients means five versions of the same phone call asking who is coming on Monday. The answer is to give each client site its own login. In the Mustr client portal, each site sees only its own roster, raises shift requests directly, ticks off flights and accommodation where that applies, and invites its own site users without you administering their accounts.
Clients get a live answer instead of a phoned one, and no client can see another client's roster, which matters when two of your clients are competitors.
The plot, kept
Losing the plot across multiple sites is rarely one big failure. It is small ones: a clash between two files, an induction assumed rather than checked, a Monday phone call answered from memory. Put every site on one timeline with hard checks at booking time and those small failures stop compounding.
If your sites each live in their own spreadsheet and the combined view lives in one coordinator's head, see it on your own roster.