Most workshops can tell you their average days to close a work order, and the figure is almost useless for doing anything about it. An average of six days could be six days of work, or four hours of work with five and a half days of waiting, and those require completely different responses. The number that matters is not how long a work order takes but where the time went — which state it sat in, and what it was waiting for. Very few fleets measure that, which is why cycle time discussions usually end with a general wish for things to be quicker. You can look at your own breakdown in a free 30-minute session.
The Average Is Not the Answer. The Breakdown Is.
Where time actually goes inside a work order, and why the total tells you nothing about what to fix.
Five States, and What Holds a Job in Each
The job exists and nobody owns it. Usually short in well-run workshops and surprisingly long where assignment happens in a daily meeting rather than continuously.
Reduce by: assigning at creation where the work type makes the owner obvious, rather than batching assignment.
The technician is ready and the machine is still working, or in transit, or at a site too far to bring in this week.
Reduce by: coordinating with the site on availability rather than waiting for the machine to arrive on its own.
Frequently the largest single block, and usually the one people underestimate because it is only visible once someone adds it up.
Reduce by: identifying parts at defect logging rather than at job start, so procurement runs in parallel with waiting.
The only state where the repair is actually happening. On most work orders it is a small fraction of the elapsed time.
Reduce by: sending the job with the fault description, photos, and history attached, so diagnosis is not repeated.
The machine is back at work and the record is still open, waiting for a sign-off, a part number, or a cost entry that nobody has completed.
Reduce by: capturing what is needed as the job finishes rather than as a separate administrative task afterwards.
What Does "Closed" Actually Mean Here?
Three different things get called closed and the difference matters. The machine is fixed and working. The work is recorded with parts, labour, and findings. The fix has been verified as effective rather than assumed.
Fleets that close on the first meaning have short cycle times and thin records. Fleets that close on the second have better records and a queue of jobs sitting in administrative limbo for days. Almost nobody closes on the third, which is why repeat failures on the same fault keep appearing as new work orders rather than as a reopened one.
The useful choice is closing on the second and tracking the third separately — did this fault recur within a defined window? That single question turns a closure count into a quality measure.
Measure Time in State, Not Just Total
Timestamps at each transition, so the block absorbing your cycle time is visible rather than argued about.
Reading Your Own Numbers
If parts waiting dominates, the problem sits in procurement timing, not in the workshop.
If waiting for the machine dominates, it is a scheduling conversation with the sites rather than a maintenance one.
If in-progress time is long relative to the job, look at whether diagnosis is being repeated for lack of information.
If work-done-not-closed dominates, the record is being treated as paperwork rather than as part of the job.
If unassigned time dominates, assignment is happening in batches when it could happen continuously.
If the average looks fine but the worst jobs are very long, the average is hiding a category of work that behaves differently.
Frequently Asked Questions
What is a good cycle time?
There is no transferable figure, because it depends on job mix, parts availability, and how far machines are from the workshop. Your own trend and your own state breakdown are worth more than any benchmark. You can work through yours on a call with our team.
Should we measure the average or the median?
Look at both, and at the worst ten percent. Averages hide the long tail, and the long tail is usually where the interesting causes are.
Is a short cycle time always better?
Not if it is achieved by closing jobs before the record is complete, or by deferring work rather than doing it. A cycle time that improves while repeat failures rise is not an improvement.
How do we track whether a fix actually worked?
By checking whether the same fault recurs on the same machine within a defined window. It is a simple query once defects are recorded per asset and per component.
Where should we start?
By recording the transitions rather than only the open and close dates. Without those timestamps every discussion about cycle time is speculation. Start with a free trial.
Find the Block, Then Fix That
Record when each work order changes state, look at where the time concentrates rather than at the total, define what closed means and apply it consistently, and track whether the fault came back as a separate measure of quality.
