Organizing maintenance tasks

The problem with managing maintenance tasks usually isn’t the tool: it’s that there are three different lists, and none of them is complete. One in the supervisor’s head, another in phone messages, and another in a notebook.

With three lists you can’t prioritize, or assign work, or know what’s fallen behind. This is about how to get to a single one.

What goes on the list

All the work, wherever it comes from, and it helps if the system distinguishes the source, because it gets analyzed separately later.

What someone requests, as an incident with its type, its priority, the client, the address and the affected equipment. It comes in from the backend, from client access with a photo, or from a mailbox the system turns into requests.

What’s due, generated by preventive maintenance based on frequency or a counter threshold.

What was found, the source that gets lost the most: anomalies detected during a review, which have to turn into a task or into an explicit decision to do nothing.

What shouldn’t go in as a maintenance task: errands, administrative tasks, accompanying a supplier. It’s not that they shouldn’t be done, it’s that if they go in as preventive work they pollute every indicator.

How it gets prioritized

By consequence, not by who insists the most.

Assets carry their own priority or criticality, and incidents carry theirs. And statuses can have an associated maximum time, through an SLA entity that defines priority and deadline.

The practical effect is that what’s overdue shows up in a list instead of being discovered when someone complains. And it distinguishes what’s urgent from what’s just noisy, which isn’t the same thing even if everything arrives tagged the same way.

If everything is high priority, priority is useless. Agreeing on what goes into each level is a thirty-minute conversation that pays for itself.

Who picks it up

Two paths, and it’s worth having both.

Assignment from planning. The calendar shows the load per technician across the weeks and lets you move work by dragging it. The most useful thing on that screen is what has no owner, which can be distinguished by color, because that’s exactly what’s going to fall through the cracks.

The technician picks it up. From the app they can see unassigned orders and take them, because they know if it’s on their way and whether they’re carrying the materials. And they can sort their own by route using GPS.

Watch out for the side effect of the second path: with an open queue, people tend to pick the easy ones, and a backlog of difficult tasks nobody takes builds up. It’s fixed with real priorities and deadlines, not by closing the queue.

What to do with what never gets done

Every list accumulates a backlog of tasks that have been sitting for months. Ignoring it has a cost: it contaminates the whole list and makes nobody trust it.

Review it once a month and decide, task by task, one of three things:

It gets done, with a real date and owner assigned.

It gets dropped, with a reason. There’s nothing wrong with dropping a task; what causes damage is leaving it there.

It becomes a plan. If it’s something that repeats, it stops being a one-off task and becomes preventive maintenance with its own frequency.

What makes the list reliable

Closing with data. A task closed with “done” doesn’t let you know later how much it cost or what was found. Time measured with a timer, materials consumed, and a checklist when there is one.

Keeping postponed work marked as postponed. If a visit couldn’t be completed, the order is left open with its reason — waiting for materials or needs a return visit — and rescheduled. Closing it as done so the plan looks fulfilled ruins the data: the percentage will say 100% and corrective work won’t go down.

Making rescheduling cheap. If updating the list costs more than ignoring it, it gets ignored, and the system ends up describing a week that never happened.

Group by area when you can

An assignment criterion that saves more than it looks like, and goes against instinct: when there are several non-critical tasks spread around, it’s worth grouping them by area, even if that delays a few of them by a few days.

Three minor visits to the same area done in one trip cost much less than three separate trips. To be able to do that, you need to see at once what’s pending and where it is, which comes from crossing the calendar with the location recorded on each asset’s record.

The limit is clear: anything with a committed deadline or risk doesn’t get grouped. That’s why priorities and maximum times need to be set correctly — they’re what determines what can wait.

Calibrated alerts

The notification system alerts the technician about what’s assigned to them, and status changes can have an associated email.

Just as important: you can mark which statuses shouldn’t trigger notifications. Alerting on every single change turns notifications into noise, people stop reading them, and then the important ones stop getting through too.

Preparing the week, which takes half an hour

A habit that saves several hours and that almost nobody has: reviewing on Friday what’s planned for the following week.

Materials. Whether scheduled orders need spare parts and whether they’re available. The minimum stock setting in warehouses and items warns you in advance, but it’s worth checking: a visit left half-done for lack of one part costs twice.

Open anomalies. If a piece of equipment due for review has something pending from the last visit, the task has two goals and needs more time than estimated.

Access. Which sites need advance notice, and whether the client knows. If they have their own access, they can see their upcoming preventive visits and organize themselves.

It’s the difference between a week that gets executed and one that gets reorganized on Tuesday.

How to know if it’s working

Three figures from the reports: accumulated unassigned orders — if they grow, assignment isn’t working —, the percentage of plan executed, and hours per technician, to see whether assignment is real or just looks that way.

And a warning about the third one: hours per technician are for sizing and distributing workload, not for evaluating anyone. A team that senses the list exists to monitor them starts logging late and rounding times, and then none of the three figures mean anything.

If you want to see how this would look with your team, you can request a demo.