Touch Time vs Cycle Time: Why Your Numbers Don't Match

A GM sends you the weekly ops report. Cycle time: 7.2 days. Touch time: 14.3 hours. The owner asks the obvious question: "So which one is it?"

Both. They measure different things. Most operators conflate them, and the conflation is why two shops with the same "cycle time" can have wildly different profitability.

Here's what each actually measures, why they diverge, and how to compute them in a way that survives scrutiny.

The Definitions

Cycle time is calendar time. It's the clock from the moment a car enters your process to the moment it leaves. If a car comes in Monday at 9 a.m. and is delivered Friday at 4 p.m., cycle time is roughly 4.3 days.

Touch time is productive time. It's the hours a technician (or estimator, or blueprinter) is actively working on the car. If the same car saw 12 hours of paint, 6 hours of body, 4 hours of refinish, and 2 hours of detail, touch time is 24 hours—regardless of how many calendar days it spanned.

Cycle time is what your customers and carriers experience. Touch time is what you pay for.

Why They Diverge

Pick any shop in your network and the gap between cycle time and touch time will tell you where the money is leaking. The gap is the waiting—parts delays, blueprinting backlog, approval cycles, rework, waiting for the customer to pick up.

A 4.3-day cycle with 24 touch hours means the car spent roughly 79 hours not being worked on. That's 77% idle. If you think of inventory like cash—which you should—you just had a car-sized chunk of cash sit in your building for three and a half days earning nothing.

The operators who run the best numbers aren't the ones with the fastest touch time. They're the ones with the smallest gap between touch time and cycle time.

Where the Gap Comes From

In order of how often we see them drive the gap at MSOs:

1. Parts procurement — ordered parts not arriving, arriving damaged, arriving incorrect.
2. Blueprint/estimate cycles — initial estimate, supplement approval, customer sign-off.
3. Rework loops — paint match failures, alignment issues, re-pulls.
4. Front-end bottlenecks — write-up queue, intake delays, DRP assignment.
5. Customer-caused delay — not available for pickup, disputing charges.
6. Internal scheduling — tech available but no work, or work available but no tech.

Each of these shows up differently in your data. Parts delay shows as "waiting on parts" status accumulation. Approval cycles show as long gaps between supplement created and supplement approved. Rework shows as multiple production steps on the same RO. If your warehouse only has "cycle time" as a number, you can't see any of this.

Computing Cycle Time Cleanly

The most common cycle time bug: using RO open and RO close dates.

RO open is often set when the customer first calls. RO close is often set days after delivery, when billing finalizes. Computing cycle time from these dates inflates the number by including pre-production and post-production time that has nothing to do with how fast you repair cars.

A cleaner definition:

cycle_time = delivery_timestamp - production_start_timestamp

Where production start is the earlier of parts-received, tear-down-started, or first-labor-hour-logged. Where delivery is the customer-pickup timestamp.

This strips out front-end and back-end noise and gives you a number that actually maps to your production process.

Computing Touch Time Cleanly

Touch time has its own traps.

Trap 1: billing labor hours, not actual labor hours. Flag hours billed to the insurance company are not the same as hours a technician spent on the car. Most MSOs measure what they billed because it's the easy number to pull. The right number is the time-clock record.

Trap 2: summing across parallel work. Two techs working simultaneously on a car for 3 hours each is 6 touch hours, not 3. If you're measuring elapsed productive time, divide by the crew size. If you're measuring labor cost, don't.

Trap 3: blueprinting, detail, and delivery not counted. Touch time isn't just metal and paint. A 90-minute blueprint and a 45-minute detail both cost you time and money.

A reasonable canonical touch time:

touch_time = sum(all labor clock-in to clock-out durations, all stages)

Computed from time-clock data, not from billed hours.

What Good Looks Like

Benchmarks vary by shop mix, severity, and DRP saturation, but rough targets we see at top-performing MSOs:

Metric	Typical	Top quartile
Cycle time (days)	6–9	3–5
Touch time (hours)	14–22	10–16
Cycle / touch ratio	6–10×	3–5×

The ratio is often a better leading indicator than either number alone. A shop whose cycle time drops but whose touch time also drops is producing faster. A shop whose cycle time drops while touch time holds flat is waiting less—usually because parts or approvals got faster.

Watch the Distribution, Not Just the Average

Averages hide everything. A shop with a 7-day average cycle time made up of 50% 3-day jobs and 50% 11-day jobs has a completely different problem than a shop with 7-day average and a tight distribution.

Report medians, p90s, and tail counts alongside averages. The long tail is usually where the money is. A 10-point reduction in the number of RO's over 21 days old is worth more than a half-day improvement in the mean.

What to Do With the Numbers

Cycle time alone drives the customer conversation. It's what your CSI score lives and dies on, and it's the number your DRP partners grade you on.

Touch time alone drives the labor conversation. It's how you understand capacity, technician productivity, and labor utilization.

The gap between them drives the operational conversation. That's where parts procurement, approvals, scheduling, and rework live—and it's where the leverage is.

If you're measuring only one, you're missing most of the picture.