How a preventive maintenance job actually runs

There’s a lot written about how a preventive maintenance plan gets planned, and very little about how it gets executed. And that’s where most of the value gets lost: a flawless plan filled in in a rush produces the same data as having no plan at all.

Here’s the journey of a preventive order, from the moment it’s born to the moment it closes with something usable inside it.

Before: the order is born on its own

Nobody creates it. Preventive maintenance generates it from the checklist attached to the asset, its model, or its family, and the frequency defined for it.

And before generating it, the system checks two things: whether that day is a holiday and whether the technician is available. Scheduling a review for a public holiday or for someone on vacation isn’t planning, it’s manufacturing a delay.

If wear depends on usage, the order can be born a different way: the asset carries a counter with a limit and a warning percentage, and when a reading that exceeds the threshold gets logged, the order generates automatically.

Preparation, which almost nobody does

The step that prevents the most failed visits, and the cheapest one.

Before heading out, it’s worth checking two things: whether there’s material needed for that checklist and whether it’s available — minimum stock in warehouses and items warns beforehand — and whether the equipment has open anomalies from the last review, because then the visit has two objectives instead of one.

A review that has to be repeated because a filter was missing costs twice as much.

At the equipment: identifying the right one

Sounds trivial, and isn’t, when there are forty units of the same model.

The QR code stuck to the asset solves that: the technician scans it and lands on the right record, with that unit’s history and documentation in front of them, without relying on a numbering scheme everyone reads differently.

Execution

From the app, without leaving the order:

The stopwatch starts when work begins. Logged times are measured, not remembered.

The checklist gets filled in point by point. On preventive orders, the app won’t let you close it until it’s complete, which is exactly the guarantee that matters for what needs proving.

Values get written down where they’re read. Fields with a minimum and maximum turn the check into a measurement, and an out-of-range reading gets logged as an anomaly on the spot.

Material gets consumed against the warehouse, with its batch when it has one.

Photos of the condition, which are half the evidence.

The signature of the person responsible, when the workflow requires it.

Everything works without coverage: actions go into a queue that empties once signal returns, and if one fails it stays marked with its reason instead of disappearing. That’s what makes this possible in a boiler room.

What gets found along the way

This is where the most value gets wasted. During a review, things get noticed: a worn belt, a small leak, a value that isn’t bad yet but is trending worse.

If that can only be jotted down as a text comment, it gets lost — nobody rereads the comments on closed orders. What’s needed is for it to be logged as an anomaly and then turned into an incident with its priority and owner, or into an explicit decision to do nothing.

If it gets logged and nothing happens, the technician stops logging it by the third time. And rightly so.

That, in fact, is how a preventive plan actually reduces corrective work: not by reviewing more, but because what gets spotted ends up as planned work instead of a breakdown three months later.

When it closes

The order ends up holding the real times, the material, the checklist with its values, the photos, and the signature. That’s what turns the review into something provable.

Statutory maintenance — which isn’t a separate module, but this same mechanism using the checklist the regulation requires — rests on that record, together with documentation and its expiry dates.

When the visit can’t happen

It happens constantly and almost no plan accounts for it: you arrive and the machine is running, the room is occupied, the client won’t give access, or a part is missing.

What you should not do is close the order as if it had been done. It’s the convenient temptation, and the one that ruins the data: the plan will show up as 100% complete and corrective work won’t drop, with nobody understanding why.

The right move is to leave it open with its reason — pending material or needs return visit — and reschedule it. In the calendar you drag it to another day, and if rescheduling costs less than ignoring the plan, the plan keeps reflecting reality.

That data point is also valuable on its own: if a type of review keeps getting postponed systematically, either the frequency is poorly chosen or the intervention window doesn’t exist. Both can be fixed, but only if they’re on record.

What to do with what’s been executed

Once a quarter, check three things in the reports:

What percentage of the plan has actually been executed. If it’s far below target, the problem isn’t the frequency: it’s that the plan is bigger than what the team can handle.

Which pieces of equipment concentrate the anomalies. It tells you whether the checks are looking where things actually fail.

Which ones have gone several cycles without a single one. They’re probably over-maintained, and that costs money too.

The three execution mistakes

Filling things in at the end of the day. Values come out rounded and hours come out low.

Checkbox-style checklists. They say someone looked, not what they saw, and they don’t let you spot a trend.

Not closing the loop on anomalies. It’s the one that kills the system.

And one planning mistake that shows up at execution time: cramming too much into each order. A forty-point checklist on a single report gets filled in worse than two twenty-point ones, and it also makes it impossible to know how much of the work got done when the visit gets cut short.

If you want to see how execution would look with your own checklists, you can request a demo.