Why do repairs take longer than the work itself?
Quick answer
A repair takes longer than the work because, for most of the time a vehicle sits at a shop, nobody is touching it. Collision data — the only part of the industry that measures this consistently — puts average keys-to-keys times at roughly nine days, against touch-time benchmarks commonly cited at two to three labour hours per day the vehicle is present. The gap between those two figures is made up almost entirely of waiting: for authorisation, for parts, for diagnosis, for capacity, and for information to travel between people who don't share a system.
This gap has a name in the collision world, where it has been measured for years: cycle time versus touch time. General repair measures it less consistently, but the pattern is the same, and understanding it explains most of what frustrates fleet operators, shop owners and customers about how repairs run.
What's the difference between cycle time and wrench time?
Cycle time is calendar time. It runs from the moment the vehicle arrives to the moment it leaves — commonly called keys-to-keys — and it includes weekends, evenings and every hour the vehicle sat in the lot.
Wrench time, or touch time, is the hours a technician actually spent working on the vehicle.
A job with twelve hours of labour completed over four days has twelve hours of wrench time and four days of cycle time. The work is identical whether it takes two days or ten. What changes is how much non-productive time sits between the productive parts.
Shops are usually measured on the first number by customers and insurers, and paid on the second. That mismatch is worth sitting with, because it explains a lot of behaviour on both sides.
How big is the gap in practice?
Collision data gives the clearest published picture. CCC's cycle time research has tracked average keys-to-keys times of roughly nine days, with newer and non-driveable vehicles running substantially longer than older ones.
Against that, industry touch-time benchmarks are commonly cited at around two to three labour hours per day that the vehicle is present, with the strongest shops reaching three and a half hours or more. The distance between those two figures — hours worked per day versus hours available per day — accounts for most of the variation in how long repairs take.
Put plainly: on a typical repair, the vehicle is being worked on for a minority of the working day, and not at all for most of the calendar day.
Collision measures this more consistently than general repair does, which is why the published figures come from that side of the industry. The pattern itself is not specific to collision.
Where do the waiting days actually go?
Five places, in roughly this order of impact.
Waiting for authorisation. The vehicle is diagnosed, the estimate is written, and then everything stops until someone approves it — a delay we've written about separately in why it takes so long to get a repair approved.
Waiting for parts. The part is ordered once the work is approved, which means the parts clock usually starts after the authorisation clock finishes rather than alongside it. A part that takes two days to arrive can add three or four days to a job depending on where it lands in the week.
Waiting for diagnosis. Intermittent faults, unclear symptoms and vehicles that need to be driven to reproduce a problem all consume calendar time with very little labour time attached.
Waiting for a bay or a technician. Shops schedule against capacity they can't perfectly predict, because a job that opens up into something larger displaces everything behind it.
Waiting on communication. Every status update, every callback, every "has anyone heard from the customer" is time that isn't spent on a vehicle — and in a busy shop it's a substantial share of the day.
Only one of those five is repair. The other four are coordination between people who each have partial information.
Why is this getting worse rather than better?
Vehicle complexity is the usual explanation, and it's part of it. More labour hours per job and more parts per job both stretch cycle time, and newer vehicles have measurably longer repair times than older ones in the collision data.
But complexity doesn't explain the waiting. A more complex vehicle needs more hours of work; it doesn't inherently need more days of sitting still. The waiting grows because every additional part, every additional approval and every additional specialist introduces another handoff — and handoffs are where calendar time is created.
The uncomfortable version is this: a shop can improve its technicians, its equipment and its processes and still not move its cycle time much, because most of the delay isn't happening inside the shop's four walls. It's happening in the gaps between the shop and everyone else.
Who pays for the waiting?
Everyone, in different currencies.
The shop pays in throughput. A bay occupied by a vehicle that isn't being worked on is capacity that can't be sold.
The fleet or the owner pays in availability — the days the vehicle spends unable to earn or unable to be used, which cost far more than the invoice records.
The customer relationship pays in trust, because the single most common complaint about a repair is not the price or the quality of the work. It is not knowing when the vehicle is coming back.
The short version
Repairs take longer than the work because the work is only a small part of the elapsed time. The rest is waiting — for approvals, for parts, for information to travel between people who don't share a system. Cycle time is a coordination measure wearing a repair measure's clothes, which is why shops that get better at repairing don't automatically get faster at delivering.
Autograff is being built around that gap. ShopOS is our product for repair shops and FleetOS is our product for fleet operators.
Key facts
- Cycle time is calendar time from arrival to collection; wrench time is the hours a technician actually spent on the vehicle. The two are routinely confused.
- Collision cycle time research has tracked average keys-to-keys times of roughly nine days.
- Touch-time benchmarks are commonly cited at two to three labour hours per day the vehicle is present, with the strongest shops reaching three and a half hours or more.
- Of the five main sources of delay, only one is repair; the other four are coordination.
- Parts delay compounds authorisation delay, because parts are typically ordered only after approval rather than alongside it.
- Improving technicians, equipment and internal process has limited effect on cycle time, because most of the delay originates outside the shop.
Frequently asked questions
- What is a good cycle time for a repair shop?
- There is no single benchmark that transfers across shop types, because cycle time depends heavily on job mix, parts availability and how quickly authorisations clear. The more useful exercise is measuring your own cycle time against your own touch time, and finding out which of the five delay categories your calendar days are actually going into.
- What's the difference between touch time and cycle time?
- Touch time is productive labour hours on the vehicle. Cycle time is total elapsed calendar time from keys-in to keys-out, including every hour the vehicle sat untouched. A job can have identical touch time and wildly different cycle times depending on how much waiting sits between the productive parts.
- How can a shop reduce cycle time?
- Most of the available gain sits in the waiting rather than the working — shortening the time between estimate and approval, starting the parts clock earlier, and reducing the number of status conversations that interrupt work. Faster technicians move touch time; they don't move the four-fifths of the delay that happens between organisations.
Keep reading.
- ShopOS
What does a missed call actually cost a repair shop?
Industry estimates put unanswered calls at tens of thousands a year per shop. The bigger problem is that a missed call leaves no record anywhere.
- ShopOS
Why has software kept failing independent repair shops?
Every generation of shop software has failed the same three tests: data entry, effort, and reliability under pressure. The whiteboard has never failed one.