Skip to content
Start Free Trial
HomeAboutPricingSupportContact
All how-to guides
How-to For engineers and technicians

Writing a work order that does not need a follow-up phone call

Most work orders are written by one person and executed by another. The gap between them is where downtime quietly accumulates.

A work order is a handover note. It travels from whoever noticed the problem to whoever will fix it, often across a shift boundary, sometimes to a contractor who has never seen the asset. Every fact missing from it becomes a phone call, and every phone call is a delay that will later be recorded as execution time.

The five facts, every time

  • Which asset — the tag reference, not "the compressor in the back".
  • What was observed — the symptom, in the words of whoever saw it.
  • When it started, and whether it is intermittent or constant.
  • What the asset is doing now — running, degraded, or stopped.
  • What access or isolation the job will need, and who can authorise it.

Five facts is a deliberately short list. A form that asks for fifteen gets three filled in properly and twelve filled in badly, which is worse than asking for five.

Symptom, not diagnosis

The most common failure in work order writing is a requester who diagnoses. "Replace the bearing" tells the technician what somebody guessed. "Grinding noise from the drive end, worse under load, started Tuesday" tells them what is actually happening and leaves the diagnosis to the person qualified to make it.

This matters commercially too. A work order that specifies a repair invites contractors to quote for that repair, whether or not it is the right one — and you will pay for the wrong repair twice.

Give "urgent" a definition

Urgency expressed as a checkbox is inflation waiting to happen: within a quarter, everything is urgent and the field carries no information. Urgency expressed as a consequence is durable.

  • Asset stopped, production affected — response in hours.
  • Asset degraded, running with a workaround — response in days.
  • Asset running normally, deterioration observed — next planned window.

Three classes, each tied to an observable state. A requester cannot argue their way up the scale without changing what the asset is doing.

The camera does most of the work

A photograph of the leak, the error code, the damaged guard or the reading on the gauge is faster to capture than a sentence and more precise than any description. It is also unambiguous later, when a contractor disputes the condition on arrival.

One work order, rewritten

Before: "Pump 3 not working, please fix urgently." That is a phone call in waiting — which pump 3, not working how, and urgent against what.

After: "Pump 3 (TAG-P-0031, Utilities). Discharge pressure dropped from 4.2 to 2.8 bar over the last two shifts, no unusual noise, still running. Photo of the gauge attached. Degraded — running with a workaround, response in days. Isolation available from the utilities panel; contact the shift supervisor."

The second version takes ninety seconds longer to write and removes the call, the second visit, and the guess.

Share LinkedIn X Email

Run this workflow on a system built for it

Every step in this guide maps to something SaharaDesk does out of the box. Book a demo and walk it against your own assets.