Field notes › Product
Who should hear about it when a shift changes?
A shift moves on a Tuesday afternoon. The dates shift by a day, or the site changes, or the worker who was on it comes off and someone else goes on. Nothing unusual. The question is who finds out, and how.
In most offices the answer is whoever gets rung, and whoever thinks to look. The coordinator remembers to text the worker. The client is told at the next catch-up, or works it out when a different person walks through the gate. The rest of the office finds out when someone asks a question nobody can answer. None of that is negligence. It is just what happens when the telling is a separate job from the doing.
Three audiences, three different needs
The worker needs to know because their week just changed. If they are flying in, the flight matters. If they have childcare booked around a night swing that is now a day swing, that matters more than the roster does. Workers who find out late stop trusting the roster, and a crew that does not trust the roster starts ringing the office to confirm everything, which costs you the time you thought you were saving.
The client needs to know because they are planning around a body on site. A different name is fine, usually. A different name they were not told about is a phone call, and a phone call about something that should have been automatic is the kind of thing that shows up later in a tender review.
The office needs to know because the roster is a shared object. If one coordinator moves a shift and the other one is mid-conversation with the same client about the same week, you look disorganised for no reason.
Silence is the default that nobody chose
Here is the part worth being honest about: early versions of most rostering systems, ours included, told people almost nothing. A worker got an email when they were first put on a shift and heard nothing afterwards. Cancelling a shift notified nobody at all. That is not a design decision anyone made on purpose. It is what you get when the notification list grows one event at a time and the ones nobody asked for never get built.
The fix is to work backwards from the events rather than forwards from the screens. What actually happens to a shift? It gets crewed. It gets changed. It gets cancelled. Somebody applies for it. A client asks for one, or amends the one they asked for. That is a short list, and each item on it has an obvious audience.
What we settled on
In Mustr, a client site now hears when their request has been crewed and who is coming, when a shift changes, with the previous details shown next to the new ones so nobody has to work out what moved, and when a shift is cancelled. Every portal login at that site gets it, along with the site's nominated contact.
Workers hear when the dates, site, or day and night status of a shift they are already on changes, when they come off a shift, and when one they were on is cancelled. Admins hear when a client raises or amends a request, and when a worker applies for an open shift, so nothing sits unseen in a queue over a weekend.
The tick that stops the noise
The risk with any of this is the opposite failure: everybody hears about everything, so everybody stops reading. Two things keep it in check.
The first is a tick on the shift form, on by default, that says let the people affected know. Untick it when you are fixing a typo in a note, or recording that something has been invoiced, or making an office-only change that has no bearing on anyone's week. The people affected are not affected, so they are not told.
The second is that drafts are silent. A shift you are still thinking about notifies nobody on either side until you release it, so the roster can be a working document without becoming a broadcast.
Let people choose the channel
Even with the right events going to the right people, one person wants email and another wants a notification on their phone and a third wants both. That is not a preference worth arguing with, so everyone picks: workers, client site contacts and the office alike get a page listing every notice they can receive, with a tick for in the app and a tick for email, set per notice or all at once.
It works in three levels, and saying them out loud helps: the organisation decides what may be sent at all, the person decides how they receive it, and the device decides whether a push actually arrives there. Anything the organisation has switched off entirely still shows on the page, marked off for everyone, so nobody sits waiting on a notice that was never coming.
The test
The test for any of this is simple. When a shift changes, does anyone have to remember to tell somebody? If the answer is yes, that is the gap, and it will be found on the worst possible week rather than a quiet one. See the rest of what has changed on the what's new page, or book a demo and bring a week that went wrong.