Field notes › Rostering
Getting roster changes to workers who are already on site
Changing next month's roster is easy. Changing tomorrow's, for a crew that is already on site, is where communication actually gets tested. The worker you need to tell has been up since 4.30am, their phone is in a locker or a ute, and if they are on nights they are asleep right now and will surface at 2pm. Whatever system you use has to survive all of that, and most of the usual ones do not.
Why texts and calls fail on site
Phone calls need the worker to be awake, off the tools and in reception, three conditions that rarely line up on a remote site. Texts do better, but they arrive into the same stream as everything else in a worker's life and sink fast. Group chats are worse: the roster change lands between a meme and a conversation about the footy, and within an hour it has scrolled out of sight.
The deeper problem is that all of these are broadcast media with no state. You sent the message, but you cannot see who has read it, and the worker cannot easily find it again at 4am when they are trying to remember whether the bus leaves at 5.15 or 5.45. The truth about their shift exists only in a message somewhere in their history, and every subsequent change adds another message contradicting the last one.
One place that is always current
The fix is to separate the notification from the truth. Messages can say something changed, but the worker needs one place that always shows their current shifts, so checking it beats scrolling. In the Mustr worker portal, a worker opens their phone and sees their own roster as it stands right now, not as it stood when the last text went out. Start times, sites, upcoming swings, all current, because it is the same roster the office is editing.
The practical details decide whether this works on a mine site. The portal runs in the browser on any phone, with no app to install, so there is no download over patchy camp wi-fi and no version that half the crew have not updated. Every login has 2FA, so it is not a security hole in exchange for convenience. A worker in a donga at 9pm can check tomorrow's start time in the time it takes to open a web page.
Notices for everything that is not a shift
Not everything you need to tell a crew is a roster change. Weather calls, camp information, a reminder about the new access road. Mustr carries notices alongside the roster, so the things workers need to know sit in the same place as the shifts they are checking anyway, rather than in a group chat archaeology dig.
Certificates get the same treatment in reverse. Expiring certs surface up to 60 days out with one-click reminder emails, and workers can upload renewed certificates through the portal from wherever they are. The conversation about a lapsing ticket happens two months early by email instead of at the gate.
Publish changes that are already valid
There is a quieter failure mode in roster communication: the change itself is wrong. The office moves a worker onto a shift that clashes with their other booking or falls outside their availability, the message goes out, and the error is discovered by the worker, on site, at the worst moment. Fast communication of a bad change is not an improvement.
Mustr checks every booking server-side against availability, double-bookings, competencies and inductions before it lands, and a failed check blocks the booking outright. So by the time a change is visible in a worker's portal, it is a change that can actually happen. Workers learn that what the portal says is reliable, which is the whole reason they keep checking it.
If your roster changes still travel by group text and hope, see it on your own roster.