Most maintenance teams assign work by availability, because availability is the only thing anyone can see. Who is free this afternoon is answerable; who has done this repair before, who is authorised to sign it off, and who needs to know it happened are all questions that live in someone's head. The result is predictable — jobs land with whoever is nearest, some get reworked because the right experience was elsewhere, and approvals get chased afterwards. Fixing it is less about hierarchy than about being explicit on four separate questions that roles usually blur together. You can map your own structure in a free 30-minute session.
The Right Task to the Right Technician
Roles that separate what someone can see, what they can do, what they must approve, and what they need to be told.
Three Questions Behind Every Assignment
Assignment goes wrong when one of these is answered and the other two are assumed.
Who is available?
The easiest to answer and the only one most systems support. Assigning on this alone is how work reaches someone who has not done it before.
Who is competent for this job?
Usually known informally by a supervisor and nowhere else. When that person is on leave, the knowledge goes with them.
Who is accountable for the outcome?
Often unstated until something goes wrong, at which point everyone discovers they held a different view of it.
Four Things a Role Should Define Separately
Which machines, sites, and records this person can view. A site engineer usually needs their own site in full and nothing beyond it; a fleet head needs the opposite shape.
Getting this wrong makes the system either useless or overwhelming, and both end in people ignoring it.
Which actions they can take — completing inspections, closing work orders, issuing parts, editing asset records. Being able to see something is not the same as being able to change it.
This is where most systems are configured too broadly, because narrowing it takes thought and opening it takes none.
What requires their sign-off before it proceeds. Releasing a machine held for a critical defect, authorising expenditure above a threshold, or closing a statutory record.
Approval that is not enforced in the system is approval that happens after the fact, which is not approval.
What they are notified about without having to look. Critical defects on their machines, overdue services on their site, parts arriving for a job they are waiting on.
The most commonly over-configured dimension. Notify someone about everything and they will read nothing.
Set Roles Around Your Actual Structure
Access, actions, approvals, and notifications configured per role and per site rather than as one permission level.
Where Assignment Commonly Breaks
Everyone gets the same permissions
Simplest to set up and the reason records get edited by people who did not do the work. It also makes the audit trail meaningless, because anyone could have changed anything.
Work assigned to a team, not a person
A job owned by four people is owned by none. Team queues work for triage; they fail as a final assignment.
Competence held only in a supervisor's memory
Functional until that supervisor is unavailable, at which point assignment quality drops sharply and nobody can explain why.
Approvals that exist on paper only
If the system lets work proceed without the sign-off, the sign-off becomes a formality collected later to tidy the record.
Nobody owns the handover
Jobs crossing shifts lose context unless the record carries it, which is where most unexplained rework originates.
Frequently Asked Questions
How granular should roles be?
Granular enough that the audit trail means something, and no more. A handful of well-defined roles works better than a role per person, which becomes unmaintainable as people move. You can work through a sensible set for your structure on a call with our team.
Should technicians be able to close their own work orders?
For routine work usually yes, since requiring supervisor closure on everything creates a bottleneck. Critical items are the exception, and that is exactly what the approve dimension is for.
How do we handle people who work across multiple sites?
Access is assigned per site, so someone can hold the same role across several without needing broader permissions than their role implies.
Can we record who is qualified for which work?
Yes, and it is worth doing, because it moves competence out of one supervisor's memory and into something the whole team can rely on.
What is the most common configuration mistake?
Over-notifying. Alert volume that exceeds what anyone can read trains people to dismiss notifications, including the ones that mattered. Start with a free trial and tighten from there.
Define See, Do, Approve and Know Separately
Give each role the view it needs, the actions it should own, the approvals it must give, and only the notifications it will actually read — then assign work to a person rather than a queue.
