The work order process is six steps and every one of them is somewhere a maintenance function loses information. A request arrives, somebody accepts it as work, somebody prioritises it, somebody assigns it, the work is done, and the job is closed with a record. Written out like that it sounds like bureaucracy; in practice each step is a decision that is being made anyway, usually by whoever is nearest, and writing them down is what makes them consistent. This page walks the six and names the failure at each.
Request and accept are two different things
A request is somebody asking; a work order is the job once it has been accepted as work worth doing. Merging them turns the board into a to-do list nobody owns and makes the backlog meaningless, because it contains both real work and things somebody once mentioned.
Prioritise from consequence, assign to a person
Three or four written levels defined by what happens if the job waits. Then a name, not a team: a job assigned to 'maintenance' is assigned to nobody and will sit until somebody trips over it. These two steps together do more for a backlog than any software.
Doing the work is where the record is made
Findings and hours, recorded at the machine at the time. Everything downstream depends on this being written rather than remembered: the schedule is priced in hours, and intervals can only be changed on evidence of what past visits actually found. It is the step that is hardest to enforce and easiest to make easier, which is the whole argument for raising and closing jobs on a phone rather than at a desk.
Closing means finished, not tidied
A job that will never be done is closed with a reason. A board tidied by deleting old jobs loses the only signal it had: which requests the function has been unable to serve and for how long. On the worked example this site publishes, the reactive share is 35% and it only means something if closure is honest.
Questions people ask about work order process
Who should be allowed to raise a request?
Anyone who sees a problem, with the lightest possible route. Restricting requests does not reduce faults, it reduces knowledge of faults.
Should every request become a work order?
No, and rejecting one with a reason is a legitimate outcome. What is not legitimate is a request quietly ageing without a decision.
How long should the process take?
From request to prioritised should be same-day; from prioritised to done depends on priority and capacity. If everything is urgent, the priority scale is not being used.