Shorten repair cycles: experiment-driven bottleneck fixes to cut fleet MTTR

Most fleets try to reduce time to repair fleet-wide by throwing bodies or overtime at the problem. It rarely works, because the delay isn't usually the wrench time — it's everything around it. A truck sitting in a bay for six hours might only have 90 minutes of actual labor in it. The rest is waiting: for parts, for a diagnostic tech to free up, for the second person needed to drop a transmission, for a bay to open.

The teams that actually move the needle treat MTTR like a lab problem. They run small, controlled experiments on one job-family at a time, measure honestly, and only then decide what to standardize. This post is about running that kind of program without turning it into a six-month consulting project.

Why "just work faster" fails

Nobody wants to say this out loud in the morning huddle: your average repair time is a blended number that hides four or five completely different problems. A brake job, an aftertreatment fault, and a coolant leak have almost nothing in common operationally. One is parts-constrained. One is diagnostic-constrained. One is labor-pairing constrained.

When you look at MTTR as a single fleet number, every improvement idea sounds reasonable and none of them are targeted. You buy a new scan tool to fix diagnostics, but your real bottleneck was that the DPF filter was three days out and nobody flagged it until the truck was already torn down.

Shops tend to optimize the visible step — labor — while the invisible steps eat 60–70% of the calendar time a unit spends down. Waiting, fetching, re-diagnosing. You can't fix what you're not separating out.

Split MTTR by job-family before you touch anything

The first move isn't a change — it's a measurement plan. Stop reporting one MTTR and start reporting it per job-family, broken into phases. A job-family is just a cluster of repairs that share a workflow shape. For a mixed medium-duty fleet, a workable starting list looks like this:

1. 1
   Brakes and wheel-ends
2. 2
   Aftertreatment / emissions (DPF, DEF, sensors)
3. 3
   Cooling system
4. 4
   Electrical / diagnostics-heavy faults
5. 5
   PM-plus (a scheduled PM that turns up defects)
6. 6
   Tires

For each family, you want total downtime split into four buckets:

Once you log even 20–30 jobs this way, the culprit usually jumps out. In a lot of shops the "wait-for-parts" bucket alone is bigger than the entire repair phase for emissions work, while brakes are almost entirely repair-phase. Same fleet, totally different fixes. This is also where a clean maintenance governance framework pays off — you already have the decision gates and review cadence to act on what the data shows instead of arguing about it.

The four experiments worth running

Keep the experiment list short. Four is plenty for a first cycle, and you run them on one job-family each, not fleet-wide. Every experiment needs a control group — the same job-family handled the old way — or you'll never know if you actually caused the change or just had a good week.

1. Pre-kitting for a parts-constrained family

Pick the family where wait-for-parts dominates — usually emissions or cooling. The experiment: build the parts kit before teardown, based on the fault code and vehicle history, so the tech never stops mid-job to go hunting.

The tricky part is defining the kit for a family that has variation. You won't get a perfect kit every time. Aim for the 80% version — the parts present in most of these jobs — plus a "likely add-ons" shelf nearby. In practice this usually cuts the wait-for-parts phase from a day-plus down to near zero on the jobs where you guessed right, and your hit-rate tells you whether the kit definition is actually working.

2. Parallel ops on labor-heavy jobs

For families where the repair phase is long and needs two people at specific moments — transmissions, big cooling jobs, suspension — the delay is often coordination, not labor. The second tech shows up late or gets pulled to something else.

The experiment: pre-schedule the second technician for the exact window they're needed, and sequence the job so solo work and paired work don't collide. Think of it like a pit stop — choreography matters more than raw speed. This ties directly into how you build the day; if your technician scheduling already accounts for cross-skilling and surge windows, pairing becomes a slot you reserve instead of a scramble.

3. A dedicated bay for one high-volume family

Bay contention is a quiet killer. A truck ready for a 90-minute brake job waits three hours because every bay is tied up with a long teardown. The experiment: fence off one bay exclusively for a fast, high-volume family — brakes, tires, quick PMs — during the trial window and don't let long jobs squat in it.

This feels wasteful. "We're leaving a bay half-idle" is the objection you'll hear, and it's exactly why most shops never try it. But throughput on the fast family usually climbs enough that total units-per-day rises even with one bay restricted. Measure units through, not bay utilization.

4. Diagnostic-first triage for electrical faults

For diagnostics-heavy families, the delay is re-work: a tech starts a repair, finds it's the wrong cause, and restarts. The experiment: require a confirmed root cause and a signed-off repair plan before the unit enters a repair bay at all. It front-loads a diagnostic step but usually collapses the repair phase, because nobody's tearing into the wrong system.

How to actually run each experiment

Don't overcomplicate the mechanics. A tight loop looks like this:

1. 1
   Pick one family and one experiment. Never bundle two changes in the same trial — you won't know which one worked.
2. 2
   Define the control. Same family, same period, handled the current way. Even a rough split (odd/even shop numbers) beats no control.
3. 3
   Set a sample size and a stop date. Aim for at least 15–20 jobs in each group, or two to three weeks, whichever comes first. Tiny samples lie.
4. 4
   Log the four phases, not just total time. Phase-level data tells you why it worked, which you need for the SOP.
5. 5
   Capture the annoying side effects. Did pre-kitting create returns of unused parts? Did the dedicated bay push another family's queue up? Write it down.
6. 6
   Compare, then decide. Winner, loser, or inconclusive. "Inconclusive" is a legitimate result and usually means your sample was too small or you changed two things at once.

The discipline here is boring on purpose. Most failed CI programs fail because someone ran a change for four days, liked the vibe, and declared victory — then the gain evaporated when the star tech went on vacation.

Here's a simple workflow to follow during a trial.

Keep the loop tight and document side effects so you know whether a winner is repeatable.

Turning a winning experiment into an SOP

A win in a trial is not a process. It's a hypothesis that survived one round. The rule of thumb that tends to work: an experiment earns SOP status when it shows a meaningful, repeated improvement across at least two cycles with different techs running it. If it only works when your best mechanic runs it, you don't have an SOP — you have a dependency on one person.

1. 1
   Trigger

   which job-family and condition activates this process

2. 2
   Steps

   the sequence, including the pre-work (kit built, second tech booked, root cause confirmed)

3. 3
   Owner

   who's accountable for the pre-work happening

4. 4
   Fail-safe

   what to do when the kit is wrong or the second tech is unavailable

Keep it to a page. SOPs that read like legal documents get ignored, and an ignored SOP is worse than none because it makes your data lie.

A realistic ROI example

Consider a regional fleet running roughly 140 trucks with a mid-size shop. Their emissions/aftertreatment family was the worst offender: average downtime around 4.5 days, most of it wait-for-parts because ordering happened after teardown.

They ran the pre-kitting experiment for three weeks on that family only — about 18 jobs kitted ahead, with a control group handled the usual way. Kitted jobs came in around 2 days of downtime; the control stayed near 4.5. Not every kit was perfect — maybe a quarter needed an add-on part — but the wait-for-parts phase essentially disappeared on the hits.

The rough math: shaving roughly 2 days off each of those repairs, on a family that hits maybe 4–5 units a month, freed up somewhere around 8–10 truck-days of uptime monthly. At their internal cost of a down unit (they used roughly $650/day for a spare-truck and lost-utilization blend), that's in the neighborhood of $5k–$6k a month recovered from one experiment on one family. The extra carrying cost of pre-built kits was minor by comparison. That result cleared the bar to become an SOP.

Notice what didn't happen: nobody worked faster, no one bought equipment, and the win came from one narrowly-scoped change. That's the whole point.

When this makes sense — and when it doesn't

This approach fits shops with enough volume that a single job-family sees at least a handful of jobs a week. If your emissions work is one truck a month, you can't run a clean trial — you'd wait a year for a useful sample. Small or very low-volume shops are better off just applying the obvious fixes (order parts before teardown, book the second tech) without the formal experiment overhead.

Running this during a genuine crisis is also a bad idea. If you're already buried and everyone's on overtime, adding controls and logging is the last thing the team can absorb. Stabilize first, experiment when there's slack to observe.

And don't run four experiments at once across four families with the same crew. You'll contaminate the results and burn out your leads. One family, one change, one clean read — then move on.

Where a system quietly helps

The measurement is the part that dies first. Nobody wants to hand-log four phases per job on a clipboard, and within a week the data has holes. This is the one place where your work-order platform earns its keep — if phase timestamps (arrived, diagnosed, parts-ready, road-tested) get captured as the job moves through its normal statuses, the split-by-phase, split-by-family reporting builds itself. You're not adding data entry; you're using timestamps the workflow already generates.

“

Use workflow timestamps instead of hand-logging phases to avoid data holes and keep experiment data reliable.

That's also what makes the SOP stick. When the system flags "emissions job created → build kit" as a task the moment the work order opens, the pre-work stops depending on someone remembering. AI-assisted platforms can handle that kind of conditional trigger reliably — the experiment result survives past the person who ran it, which is the only way MTTR gains actually compound instead of resetting every quarter.

The takeaway

Cutting fleet MTTR isn't a single project — it's a habit of splitting the problem small, testing one change at a time, and only standardizing what survives a real trial. Separate your downtime by job-family and phase, run a few tight experiments, promote the winners to one-page SOPs, and let the numbers — not the loudest tech in the room — decide what stays.

Do that a couple of cycles a year and the fleet-wide number moves on its own, because you fixed the actual bottlenecks instead of guessing at them.

Do that a couple of cycles a year and the fleet-wide number moves on its own, because you fixed the actual bottlenecks instead of guessing at them.