The work order is the atomic record of fleet maintenance. Everything downstream — cost per mile, failure analysis, warranty recovery, replacement timing, vendor performance — depends on work orders being complete and correctly coded.
Most fleets capture cost and skip cause, which makes their maintenance data useful for accounting and useless for engineering.
What a work order must capture
| Field | Why it matters |
|---|---|
| Asset and odometer at time of work | Ties cost to usage; drives interval scheduling |
| Reported symptom | What the driver or inspection found |
| Diagnosis / cause code | Why it failed — the field most often skipped |
| System / component code | Enables failure analysis by system |
| Work type | Planned, unplanned, running repair, accident, recall, campaign |
| Labour hours by technician | Real workshop cost and productivity |
| Parts used, with part numbers | Cost, usage patterns, warranty |
| External vendor costs | Complete picture on mixed jobs |
| Downtime start and end | Availability calculation |
| Priority and status | Workflow control |
| Warranty flag | Recovery opportunity |
The two fields that separate useful data from noise are cause code and downtime. Without cause, you cannot analyse failure patterns. Without downtime, you cannot compute availability or the true cost of a failure.
"Brake warning light" is a symptom. "Wheel speed sensor failure due to corrosion" is a cause.
A workable status model
Keep it short. Long status lists get used inconsistently.
- Requested — raised, not yet reviewed
- Approved — authorised to proceed
- Awaiting parts — blocked, and this must be visible
- In progress — work underway
- Awaiting authorisation — cost exceeded the limit mid-job
- Completed — work done, vehicle available
- Closed — costs finalised, invoices matched
"Awaiting parts" deserves its own status rather than being hidden inside "in progress". It is usually the largest single contributor to downtime, and it is invisible if not separately tracked.
Approval thresholds
Define authority levels by value, and enforce them in the system:
| Value | Approver |
|---|---|
| Routine, below the first threshold | Workshop supervisor |
| Mid-range | Depot or fleet manager |
| High value | Fleet manager plus finance |
| Above replacement-decision threshold | Formal repair-versus-replace review |
The last row matters and is frequently missing. A major repair on an old vehicle should trigger an explicit decision, not a routine approval. Fleets without this control regularly spend more on a repair than the vehicle's remaining value justifies.
Approvals must be fast. A threshold that delays work by two days costs more in downtime than the control saves, so set the routine limit generously and reserve scrutiny for genuinely significant spend.
Capturing labour honestly
Labour is the largest workshop cost and the most poorly recorded.
- Clock on and off jobs, not at the start and end of the day.
- Separate diagnostic time from repair time — it is a genuine cost and an indicator of technical difficulty.
- Record rework separately from the original job, or repeat-repair analysis becomes impossible.
- Include road test and cleaning time where they are real.
- Track technician productivity as hours booked to jobs against hours attended, but treat it as a workshop-management metric rather than an individual scorecard.
Internal and external work on one record
Mixed jobs are common: internal diagnosis, external specialist repair, internal refit. The work order must hold both cost streams on a single record, or the true cost of the failure is split across two systems and never reassembled.
Confirm during software evaluation that a single work order supports internal labour lines and external vendor invoice lines simultaneously, with a combined total.
The reports that make it worthwhile
- Cost by system and component across a vehicle class, revealing design or specification problems
- Repeat repairs within 30 days, by vehicle and by technician — the key quality signal
- Top ten vehicles by maintenance cost per mile, updated monthly
- Downtime by cause, separating parts wait, workshop capacity and diagnosis
- Warranty recovery achieved against available — see warranty recovery
- Vendor performance: cost, turnaround, rework rate
None of these are producible without cause codes and downtime capture, which is why those two fields are worth enforcing even when the workshop resists.
Frequently asked questions
How detailed should cause coding be?
Detailed enough to support analysis, simple enough to be used consistently. A structured list of a few dozen system and cause combinations, selected from a picker, works far better than free text or a taxonomy with hundreds of entries that technicians pick at random.
Should drivers raise work orders directly?
Drivers should raise defects; a supervisor converts them into work orders after triage. Direct work order creation by drivers tends to produce duplicates and misdiagnosis, while defect reporting captures the information you need at the point it is observed.
How do we handle work done at roadside by a breakdown service?
Create a work order with the external cost, the cause and the downtime, even though no internal labour was involved. Roadside events are exactly the failures you most need in your analysis, and they are the ones most often missing from fleet data.
What is a reasonable work order closure time?
Costs should be finalised within days of the physical work, not weeks. Long-open work orders distort monthly cost reporting and make period comparisons unreliable. Report on open work orders older than a defined age.
Should we record work orders for statutory inspections?
Yes, as a distinct work type. They are a real cost and a real downtime event, and separating them from repair work keeps your unplanned-to-planned ratio meaningful.
