Self-assignment of work orders: how it works

In almost every maintenance department there’s one person who spends the day handing out work. It’s a silent bottleneck: when that person is in a meeting, on vacation, or simply busy, work orders sit without an owner, and a work order with no owner is one that falls through.

Self-assignment tackles that through two distinct routes that shouldn’t be confused: work getting picked up by whoever’s going to do it, and work getting assigned by rules you’ve configured.

Route 1: the technician picks it up

It’s the simplest, and the one that takes the most off the planner’s plate.

From the app, a technician can see the work orders that don’t have an assignee and take them on. It sounds minor and it changes day-to-day operations quite a bit, because whoever’s out in the field has information the office doesn’t: whether it’s on their way, whether they’re already carrying the material in the van, whether they’re already heading to that site for something else.

Along the same lines, they can order their work orders by route using GPS, so they’re not crossing the city twice. Travel is the single biggest cost item in almost any field-technician operation, and this is the most direct lever on it.

For this to work, unassigned work needs to be visible. In the calendar you can distinguish by color what has no technician, precisely for this reason: what’s visible gets picked up, and technicians organize themselves better among each other when they’re all looking at the same picture.

Route 2: rules that assign on their own

The second route is the system assigning work according to criteria you’ve defined.

Worth being precise here, because this is where most of the confusion is when people talk about automation: these are deterministic rules, not a model that guesses. That means three concrete things:

• You decide them, and they can be switched off.
• They leave a record of every decision, with its reason.
• They’re reversible: a wrong assignment gets changed like any other.

That combination —configurable, traceable, and reversible— is what makes it acceptable to automate a step that someone is accountable for. Without it, what you have is a system handing out work for reasons nobody can explain.

What information it needs to get it right

An assignment rule is only as good as the data behind it. The ones that matter most:

Availability. Shifts, working hours, vacations, and public holidays, which in GMAO Cloud live inside staff management for exactly this purpose. In fact, before generating a preventive order the system already checks whether the day is a holiday and whether the technician is available: assigning work to someone on vacation isn’t planning, it’s manufacturing a delay in advance.

Team and manager. Technicians are grouped into teams with their own lead, so work can be assigned to the team and each manager sees their own without having every order in the company in front of them.

Client and zone. An incident carries its client, its address, and its zone, which is what lets you distribute work by territory instead of by order of arrival.

Priority and deadline. Statuses can carry a maximum time attached, and there’s an SLA entity with its own priority and limit. Without that, everything comes in marked urgent and assignment can’t tell them apart.

What shouldn’t be automated

Priority. What gets handled first is decided by someone with the context in front of them: which client has a committed deadline, which line is stopping production, which inspection can’t slip another month. A rule can order the queue; it can’t decide what matters today.

Closing the order. If a job can be closed without anyone confirming it was actually done, the history stops being worth anything as proof.

How critical an asset is. It’s a business decision, not a calculation.

And artificial intelligence, to be precise

Worth not mixing this in with the above, because they’re different things, and presenting them together just to sound more modern would do everyone a disservice.

GMAO Cloud’s AI features don’t make decisions: they read, answer, and suggest, and whatever gets applied is applied by a person. They don’t assign work or close orders. What they do is something else entirely —an assistant over your assets and history, document reading, help drafting the order’s text— each with its own switch, and most turned off by default. It’s covered in detail in AI in GMAO Cloud.

Rule-based assignment is a configurable automation. It’s not the same thing, and the distinction matters when you have to explain why the system did something.

The side effect almost nobody sees coming

When unassigned work is visible and anyone can take it, a behavior shows up that wasn’t in the plan: technicians start cherry-picking the easy ones.

It’s not bad faith. Faced with an open list, anyone will pick the thirty-minute inspection over the ten-minute one before they’ll pick the complicated breakdown on the other side of the province. If it’s not watched, after a few weeks you’re left with a residue of orders nobody takes, and those are exactly the ones that are most urgent.

You fix it without removing self-assignment, with two things. First, making sure incidents actually carry priority and a deadline, so overdue work stands out instead of aging silently. Second, periodically checking the unassigned queue: if it keeps growing, the open route isn’t solving the distribution problem, it’s just postponing it.

How to tell if it’s working

With the reports, watching three things over time:

Hours by technician. Whether the distribution is real or just looks balanced on paper. It’s the first thing that gives away a badly set rule.

Accumulated unassigned orders. If they keep growing, the automation is generating a backlog instead of resolving one.

Deviation between estimated and actual time. If one technician deviates a lot more than the rest on the same type of job, it’s almost never that they work worse: it’s usually that they’re being assigned work that isn’t a good fit.

A word of caution about this data: it’s for sizing and distributing workload, not for monitoring people. A team that senses the system exists to watch them stops feeding it accurate data, and at that point none of the above measures anything anymore.

Where to start

With route 1, which requires configuring nothing: make unassigned work visible and let technicians pick it up. Within a few weeks you’ll see which patterns of distribution emerge on their own, and those are the ones worth turning into rules.

Setting up rules on day one is configuring blind, because there’s no history yet to tell you which criteria actually make sense.

If you want to see it with your own team and shifts, you can request a demo.