Field notes › Compliance
Why competency spreadsheets fail past 20 workers
Every labour hire firm has owned the spreadsheet. Workers down the side, tickets across the top, expiry dates in the cells, maybe some conditional formatting that turns things red. At ten workers it genuinely works. Somewhere past twenty, it stops working, and the dangerous part is that it does not look any different when it stops.
Why small works and bigger does not
With a small crew, the spreadsheet is not really the system. The coordinator's head is the system, and the spreadsheet is their notepad. They know whose crane ticket is the one to watch and which new starter has not done the second induction yet. The sheet just backs up what they already know.
Growth breaks this quietly. More workers, more tickets per worker, more client sites with their own induction lists, and the grid grows in both directions until no one person holds it in their head anymore. The spreadsheet is promoted from notepad to source of truth without anyone deciding that, and it was never built for the job.
Nobody owns row 47
A spreadsheet has no idea when it is wrong. A worker renews a ticket and the paper goes into a glovebox. A cell gets pasted over during a hurried edit. Someone saves a copy to their desktop to work offline and now there are two versions, each partly right. None of this announces itself. The sheet displays stale data with exactly the same confidence as fresh data, and every person who opens it reasonably assumes someone else is keeping it current.
Contrast that with a system where workers upload their own certificates through a portal on their phone, the record has one live copy, and expiring certs surface themselves up to 60 days out with one-click reminders. The maintenance burden moves from one overloaded coordinator to the people who actually hold the certificates.
The matrix is not connected to the roster
This is the flaw that matters most, and it holds even for a perfectly maintained spreadsheet. The competency matrix and the roster are two different documents, and the only bridge between them is a human remembering to look. Every booking depends on someone cross-referencing the sheet at the moment they allocate the shift. On a quiet Tuesday, they probably do. During a shutdown scramble, at night, covering for a colleague, they sometimes do not, and the spreadsheet has no way to object.
Mustr closes that gap by making the check part of the booking itself. Every booking is verified server-side against the worker's competencies, inductions, availability and double bookings before it exists, and a failed check blocks the booking outright. The matrix and the roster stop being two documents. There is one system, and it refuses to contradict itself. The compliance page has the detail.
The failure mode is silent until it is loud
Here is what makes the spreadsheet genuinely risky rather than just untidy: it fails silently. A red cell nobody scrolled to is invisible. A worker rostered against an expired ticket generates no error, no alert, nothing. The first sign of the problem is external, a client audit, a site access check, or worse, an incident investigation asking why this person was doing that task. By the time a spreadsheet failure is visible, it has usually already cost you something.
Past twenty, change the tool
None of this means anyone did a bad job. The coordinator holding a fifty-worker matrix together with vigilance and conditional formatting is usually doing a heroic one. But heroics are not a system, and the fix is not a better spreadsheet. It is moving the checking from a person who might to a system that always does.
If your matrix has outgrown the person maintaining it, see it on your own roster.