Field notes › Rostering
The roster handover: keeping office and site on the same page
Somewhere in your sent items is a file called something like Roster_v7_FINAL_final.pdf. The site printed v5 and pinned it to the crib room wall. The client's supervisor is working off v6, which he forwarded to himself from a meeting three weeks ago. Everyone is confident. Nobody is right. That is the roster handover in most labour hire firms, and it fails in a very specific way: not when the roster is made, but every time it changes afterwards.
Why attachments fail as handovers
An emailed roster is a photograph of a moving object. It was accurate at the moment of export and started decaying immediately, because rosters change constantly. A worker swaps a swing, a client adds a Saturday, someone falls sick, and now the truth has moved on while the photograph circulates.
The failure is built into the format. Attachments get printed, forwarded, saved to desktops and pinned to walls, and every copy becomes its own little source of truth. You cannot recall them, and you cannot tell which copy a site supervisor is reading when he rings to say the roster is wrong. Versioning discipline helps for about a fortnight, until the first urgent change goes out as a quick email instead of a new version.
One live roster beats every attachment
The handover problem disappears when there is nothing to hand over. Give the site a login instead of a file. In the Mustr client portal, each client site has its own login and sees its own roster, live. When the office changes a shift, the site is looking at the changed shift, because there is only one roster and both sides are reading it.
Each site sees only its own roster, nothing belonging to any other client, and each client can invite its own site users rather than routing every new supervisor through your office. The person who actually needs the roster at 5am can see it without waiting for anyone to hit send.
Requests instead of phone calls
Handover is not one-directional. Sites push changes back: two more for Thursday, drop the Sunday shift, can we get the same operator as last swing. When those arrive as phone calls and texts, they land on whoever picked up, and some of them evaporate before reaching the roster.
In the client portal, the site raises a shift request directly, and the office actions it on the roster where both sides can see the result. For FIFO work, the client can also tick off flights and accommodation on the shifts themselves, so the travel state is shared rather than relayed. The request stops being a memory of a phone call and becomes a thing with a status.
A record you can both point to
Even with a live roster, disagreements happen. The site swears they asked for three workers, the office swears the request said two. With phone calls, that argument is unwinnable and someone eats the cost to preserve the relationship.
An audit trail changes the conversation. Every change to the roster is recorded, so who changed what, and when, is a lookup rather than a debate. That protects both sides. Your client is not relying on your coordinator's memory, and your coordinator is not being held to a version of events reconstructed from a supervisor's recollection of a Tuesday phone call. Disputes get shorter and less personal when the record is shared. There is a walkthrough of how the pieces connect at how it works.
What the handover becomes
With a live portal, requests in the system and a shared record, the handover stops being an event and becomes a standing state: office and site reading the same roster all the time. The Sunday night export ritual quietly disappears, and with it the whole category of problems caused by people acting on old photographs of the roster.
If your handover still travels as a PDF with a version number, see it on your own roster.