Writing a work order somebody can actually action
A large share of maintenance time is spent working out what a job means. That time is charged to the job and blamed on the technician.
The most common work order in circulation reads something like 'light not working, second floor'. It contains a symptom, an approximate location, and nothing else. For a separate product-side perspective on writing a clear, evidence-based record, this template guide provides additional detail.
A technician receiving it has to find the light, establish whether it is a lamp, a fitting, a driver, a switch or a circuit, discover they need a part they did not bring, and return. Two visits, an hour of walking, and a job that was recorded as taking two hours of labour to change a lamp.
Six fields that remove most of the ambiguity
- Asset identifier, where one exists, rather than a description of where the thing is.
- Precise location — floor, room number, and position within the room.
- Observed symptom, stated as an observation rather than a diagnosis. 'Making a knocking noise when it starts' is more useful than 'bearing gone'.
- When it started and whether it is intermittent or constant.
- Access constraints: who holds the key, whether the area is occupied, whether an isolation or a permit is needed.
- Reporter and how to reach them, because half of all ambiguous jobs are resolved by one question.
None of this is onerous when the reporting form is designed to collect it. All of it is missing when reporting happens by email or by someone mentioning it in a corridor. For a wider operational and compliance reference, consult OSHA hazard identification guidance.
Reporters who diagnose send technicians toward a conclusion that may be wrong, and the wrong part gets brought. Record what was observed and let the diagnosis happen on site.
Make the reporting route single and easy
Where reporting is possible through four channels — a form, an email address, a phone call, a message to a technician directly — the informal ones win, and the jobs that arrive through them carry no data and often no record at all.
One route, easy enough that it is not worth circumventing, and a firm convention that a job reported another way gets logged before it gets done. The second half is the harder discipline and it is what determines whether the work order history describes reality.
Distinguish the request from the job
A reported request may become one job, several jobs or none. Merging the two causes trouble later: a single report of 'it's cold in the office' can be a valve, a control setting, a failed unit and a window that will not close.
Keeping the request as a separate record that spawns work orders lets you close the request when the person is satisfied and close the jobs when the work is done, which are genuinely different events.
Include what a competent person still would not know
A work order does not need to explain how to do the job. It needs to carry the information a competent technician could not get on their own: the history of this asset, the previous attempt that did not work, the tenant's constraint about access hours, the fact that the isolation valve is behind a locked panel.
This is where the value of the maintenance record is realised. A system that shows the last three jobs on the same asset when a new one is raised prevents the recurring failure being treated as new every time.
Write the acceptance condition
State what completion looks like, particularly for anything that is not obviously binary. 'Restore heating to the meeting room' is checkable; 'look at the heating' is not, and it will be closed by someone who looked at it.
For jobs that cannot be fully resolved on the visit, the acceptance condition is what makes a partial completion honest — made safe, isolated, parts ordered — rather than a closure that hides an unresolved problem.