Field notes › Product

Seeing the clash before you book it

There are two different questions hiding inside the word available, and rostering software that treats them as one question will waste your afternoon.

The first question is whether the worker says they can work. That is declared availability: the days they have marked as free in their own calendar. The second question is whether they are actually free, which is a fact about the roster rather than a statement of intent. Someone can have Monday to Friday marked available and still be locked into a fourteen day swing at another site that started last Wednesday.

How the failure feels

You open a shift that needs crewing. The list of available people includes a worker who suits it, so you pick them. The save fails, or worse it succeeds and the double-booking surfaces two days later when the other site rings.

Either way you have spent the effort of making a decision and then had it taken back. Do that three times in a morning and coordinators start keeping a private mental map of who is where, which is exactly the spreadsheet-in-someone's-head that the software was supposed to replace.

Grey, not gone

The obvious fix is to remove the clashing worker from the list. It is also the wrong fix, and it took us a version to work that out.

My rosterCards, not a timeline squeezedonto a handset.Current shift pinned on topCountdown, site, day or nightLength and confirmed statusFlights and accommodationAdd to my calendar, one tapOn site nowNorth Site · DayIn 3 daysWest Site · NightIn 11 daysNorth Site · DayIn 24 daysWest Site · Day
The crew's roster on a phone: the current shift on top, the rest as cards.

If someone simply is not there, you do not know why. Are they missing a ticket? Did they mark themselves unavailable? Have they left? A coordinator who cannot see them will go looking, or worse, will ring them, and now the software has generated a phone call rather than saved one.

What works is showing them, greyed, with the reason on the card: the site they are on and the dates that clash. That is a complete answer. You know not to pick them, you know why, and if the other site's shift is the one that should move, you know where to go.

The same logic applies to tickets. A worker who does not hold the competency the site requires is more useful shown greyed with the missing ticket named than quietly filtered out of existence, because the missing ticket might be one you can chase before Monday.

Do not let someone clash with themselves

A small detail with an outsized nuisance value: when you edit an existing shift, the person already on it must not count as clashing with themselves. It sounds obvious. It is also exactly the sort of thing that slips through, and the symptom is bizarre enough to erode trust in the whole panel. You open a shift to change its end date, and the person on the shift appears greyed out with a clash against the shift they are already on.

What a good crew panel shows

Once the panel is the place where the decision gets made, it needs to carry enough to make it. For each person: who they are and their role, the competencies they hold that this site actually requires and whether those are verified and current, the exact dates they are free within the window you are filling, including partial fits, and any clash, named.

Partial fits matter more than they sound. A shift running Monday to Friday and a worker free Wednesday to Friday is not a yes or a no, it is a conversation about splitting the shift or shortening it. A system that answers only yes or no makes you go and find that out by hand.

Put the people who want it in front of you

The other half of the same screen is who has put their hand up. Expressions of interest used to live on a separate requests tab, which meant building a roster was a loop: open the shift, go to the tab, remember who was keen, come back, assign. Both halves of the decision belong on the shift itself, so whoever applied is listed there, one tap to assign, and the compliance check still runs before anything is booked.

The general rule

Software should tell you what it knows at the moment you are making the decision, not at the moment you try to save. Anything that waits until the save to object has turned a piece of information into an error message, and error messages are a poor way to learn how your own roster fits together.

The rostering page covers the rest of the shift editor, and a free trial is loaded with enough sample crews and shifts to make clashes happen on purpose.

Bring one roster to the demo. We'll show you Mustr running it.

Book a 20-minute demo