Field notes › Rostering
How far ahead should you publish the roster?
Every rostering conversation eventually reaches the same argument. Operations wants to publish four weeks out so the crew can plan their lives. The coordinator points out that four weeks out is fiction, because the client will change half of it. Both are right, which is why the argument never resolves on its own.
Two different things are being published
The argument gets easier once you separate the roster into what is committed and what is intended.
A committed shift is one you would ring someone about if it changed. Somebody is named, the client has confirmed the requirement, flights might be booked. An intended shift is a plan: this site will probably want four people that week, and here is roughly who.
Trying to publish both with equal confidence is what causes the trouble. The crew treats an intention as a commitment, plans their week around it, and is annoyed when it moves. The office learns that publishing early causes complaints, so it publishes late, and the crew loses the ability to plan at all.
Let drafts be visible to the right audience only
The useful middle is a shift that exists, is visible to the people who need to see the plan, and is not yet a promise to the worker.
In Mustr a draft shift shows on the client's roster as an unassigned, dashed shift, so the client can see cover is in motion before anyone is named, and it stays view-only on their side until you release it. Your own crew see nothing until it is released. That combination is doing something specific: the client gets confidence, the worker does not get a commitment you cannot keep, and the office keeps a working document.
Whatever system you use, look for that distinction. If a shift is either invisible or fully published, you will end up choosing between an anxious client and an annoyed crew.
Pick a horizon per site, not per company
A shutdown site and a steady-state site do not deserve the same horizon. A long-running maintenance contract with predictable numbers can be published a month out and will barely move. A shutdown or a project with weather exposure cannot be published a month out with a straight face.
Setting the horizon per client site, and telling the crew what the horizon is for each one, converts an unspoken expectation into a stated one. Two weeks firm at the steady site, one week firm at the project site, is a policy people can live with. Silence is not.
Say the number out loud
The specific thing that makes rosters feel unreliable is not that they change. It is that nobody said how much change to expect. If the crew knows the next seven days are firm and anything beyond that is indicative, a change at day ten is normal. If nobody has said anything, a change at day ten is a broken promise.
Put it in the induction pack, and repeat it when the roster goes out. It costs nothing and it converts a large amount of grumbling into a shrug.
Make amendments cheap
If publishing early is going to work, changing things has to be cheap for everyone, which mostly means nobody should have to remember to tell anyone.
When a shift moves, the worker on it should hear automatically, with the previous details shown next to the new ones so they can see what changed. The client site should hear the same way. The office should be able to make an office-only correction without mailing anybody, which is why the notify tick on the shift form matters: it is on by default and you untick it when the change genuinely affects nobody.
Once amendments are that cheap, the case for publishing early gets stronger, because the cost of being wrong has dropped.
A workable default
If you want somewhere to start: keep the next seven days genuinely firm and treat any change inside that window as an exception worth a conversation. Publish committed shifts two to three weeks out. Keep anything beyond that as drafts, visible to clients as planned cover and invisible to the crew. Review the horizon per site once a quarter rather than arguing about it weekly.
The rostering page covers how drafts, open shifts and assigned shifts differ, and the client portal page shows what the client sees while a shift is still a plan.