Work order cycle time: how long a job really takes, from request to closed
A work order is raised on a Monday in July for a minor gearbox inspection. It sits in the planner's queue, then waits for a part, then waits for a scheduled slot, and finally gets done in December.

A work order is raised on a Monday in July for a minor gearbox inspection. It sits in the planner's queue, then waits for a part, then waits for a scheduled slot, and finally gets done in December.
Nobody deliberately delayed it. It simply moved through the natural friction of the maintenance process: backlog, planning, kitting, waiting for equipment access, execution, and at last the data entry that closes it out. Work order cycle time captures all of that friction in a single number of days.
What it actually measures
Work order cycle time is the number of days from the date a work order is created to the date it is closed in the system, including every stage in between: planning, sourcing materials, waiting for access, doing the work, and final close-out. It can be reported as an average across a period, as a distribution across time bands, or as a count of orders closed in each range.
How to work it out
Work order cycle time (days) = Completion date - Creation date
Take seven orders closed in December, with cycle times of 153, 117, 94, 64, 13, 9 and 4 days.
Average cycle time = (153 + 117 + 94 + 64 + 13 + 9 + 4) / 7 = 64.9 days
An average near 65 days, with five of the seven taking more than a fortnight and three running past 90 days. Each of those long ones is worth opening up to see whether the delay was planning, parts, or equipment access.
Why it points at the process, not the people
Here is the most useful thing to understand about cycle time: most of the days it counts are not days of work, they are days of waiting. The wrench itself might touch a job for only a few hours; the rest of those weeks was spent queuing for planning, for parts, for a permit, for the equipment to come free. That is why a long cycle time is almost never an indictment of the technicians and almost always a portrait of the process around them. It measures the friction in your work-management pipeline, the gaps between the jobs rather than the jobs themselves, which is exactly where time leaks out of a maintenance operation and exactly where it can be recovered.
What good looks like
There is no universal benchmark, and that is not a gap in the metric but its nature: cycle time swings so widely with industry, equipment and priority that any single target would be meaningless. Treat it as an internal diagnostic, not a number for league tables. Set your own targets by priority class, the same urgency tiers used for aging, and watch the trend and the long tail. A short average is good news only if it is not hiding something, because lots of easy reactive jobs closing in a day can pull the mean down while the planned work that matters quietly ages behind it. Always look behind the average at the distribution.
Where it can mislead you
Work order cycle time measures the full journey from request to closed record, and that whole journey is where time quietly leaks out of a maintenance operation. Watch it, break it into its stages, and it will point you straight at the part of your process that most needs fixing next.



