Field notes › Choosing software
Choosing rostering software when you run labour hire
Most rostering software was built for a cafe or a single warehouse. One workplace, one manager, a pool of staff who all belong to that workplace. Labour hire does not work like that, and the software you pick needs to know it.
You are placing workers across multiple client sites, often in different towns, sometimes on the other side of the country. The people on your roster hold competencies and inductions that decide whether they are allowed on site at all. Your clients want visibility without seeing each other's business. Get the wrong tool and you end up running the real roster in a spreadsheet anyway, with the software reduced to an expensive timesheet.
Start with the shape of your roster
A single-site roster is a grid: days across the top, staff down the side. A labour hire roster is a timeline across many sites at once. You need to see every client site in one view, day and night shifts, swing patterns for remote work, and the gaps you still have to fill. If the software forces you to run one roster per client and flick between them, double-bookings are a matter of time. Nobody can hold six separate rosters in their head.
Look for one roster timeline across every client site, with open shifts workers can register interest in. That last part matters more than it sounds. Filling a dropped shift by ringing down a list is slow. Publishing it as an open shift and letting qualified workers put their hand up is faster, and it leaves a record.
Compliance belongs inside the booking, not beside it
In labour hire, a roster mistake is not just an awkward conversation. Sending someone to a mine site without a current induction or the right competency can get your crew stood down and your contract questioned. So ask the sharpest question in any demo: what happens when a scheduler books a worker who does not hold the required ticket?
Most tools flag it. A little warning icon, easily clicked past at 9pm when someone is scrambling to cover a shift. Better tools block it. Mustr checks every booking server-side against the worker's competencies, inductions, availability and existing shifts before it is booked, and a failed check stops the booking outright. Expiring certificates surface up to 60 days out with one-click reminder emails, so the block rarely gets the chance to fire.
Workers and clients need their own windows
Your schedulers are not the only people who touch the roster. Workers need to see their own shifts, set availability, check open shifts and upload certificates without ringing the office. And they will not install another app for a casual employer. A web portal that works on any phone beats a native app for a labour hire crew every time.
Clients are the other half. Each client site should get its own login, see only its own roster, raise shift requests, and tick off flights and accommodation. That kills a whole category of Monday morning emails, and it removes the awkward possibility of one client seeing another client's crew.
Watch the pricing model
Per-seat pricing punishes the exact thing labour hire does: carrying a big pool of casual workers, most of whom work some weeks and not others. If you pay per worker, you either pay for the whole pool or spend your life deactivating and reactivating people. Flat pricing per organisation, stepped by crew size, is a better fit for the way a casual pool behaves. Everything included in one price also means you are not discovering mid-contract that the audit trail or the client portal sits in a higher tier. Mustr publishes its flat monthly pricing for exactly that reason.
A short test before you sign
- Can I see every client site on one roster timeline?
- Does a failed compliance check block the booking, or just warn?
- Can workers use it on their phone without installing anything?
- Does each client get a login that shows only their own site?
- Is the price flat, or am I paying for every casual on the books?
If a product passes those five, it was probably built for labour hire rather than adapted to it after the fact. Most were adapted, and it shows within the first month of real use.
If you want to see how Mustr answers them, book a demo.