Field notes › Industries
Rostering for mining labour hire: what makes it different
Most rostering software gets built for cafes, retail and aged care. Weekly patterns, one location, workers who go home every night. Then a labour hire firm supplying mine sites tries to use it and ends up fighting the tool every single day. Mining work is a different shape, and the differences sit exactly where the risk does.
Swings, not shifts
A mine roster runs in blocks. Two and one. Eight and six. Whatever pattern the site runs, your people fly in, work a stretch of days and nights, then fly out. A tool that thinks in weekly repeating shifts makes you hand-build every swing, and it has no idea that a worker finishing a swing on Thursday cannot start somewhere else on Friday because they are on a plane home.
You need a roster that treats the swing as the unit of work: the day shifts, the night shifts, the changeover in the middle, and the travel on either side. Mustr's roster timeline was proven on remote Australian mine sites, so swing patterns and day and night shifts are the default, not a workaround you build in a spare column.
The site decides who can work
On a mine site the client does not care that a worker is free that week. They care that the worker holds the right competencies and has completed that site's inductions. Every site keeps its own list, and a worker who is fully cleared for one client can be a compliance breach at the next one.
Spreadsheet-era firms handle this with a human check. Someone eyeballs the matrix before confirming the booking. That works until the request comes in late, the matrix is stale, or the person who knows the matrix is on leave. Mustr runs the check server-side at the moment of booking, against competencies, inductions, availability and double bookings, and a failed check blocks the booking outright. Not a warning you can click past. A hard stop. There is more on how that works on the compliance page.
One worker pool, many client sites
A venue rosters one location. You roster the same pool of people across every client you serve, and that is where double bookings come from. The coordinator working one client's roster cannot see what the coordinator on another client's roster promised an hour ago. One roster timeline across every client site fixes this structurally rather than procedurally. If a worker is committed anywhere, the system will not let them be booked somewhere else for the same dates, no matter who is doing the booking.
Getting people to site is part of the roster
For FIFO crews the flight and the room are as much a part of the shift as the start time. When travel lives in someone's inbox or a separate spreadsheet, things get missed, and a missed flight to a remote site is not a small problem. There is often no second flight that day, and the site is short a worker for the whole swing.
Mustr tracks flights and accommodation on the shift itself, where they belong. Each client site gets its own portal login, sees only its own roster, and can tick off flights and accommodation as they are arranged. Both sides can see what is booked and what is still hanging.
What this adds up to
You can bend a generic rostering tool into mining work. Plenty of firms do, with helper spreadsheets and tribal knowledge filling the gaps. But the bending is where the mistakes live: the swing built by hand, the induction nobody rechecked, the flight tracked somewhere else. Software built for this work removes the bending, and with it most of the ways a booking goes wrong.
If your crews work in swings across client sites, see it on your own roster.