Why tech performance data should be running your bay assignments — not seniority or guessing

The traditional way (and what it costs you)

Walk into 100 service drives and ask how cars get assigned to techs. You'll get three answers, weighted roughly like this: 60% "the lead tech grabs what he wants, the rest gets distributed by the advisor or shop foreman." 25% "round-robin, next car goes to next tech." 15% "we have a system." The 60% camp doesn't think of it as a system, but it is — it just isn't optimized for anything in particular.

The traditional way has three structural problems:

1. It optimizes for the senior tech's hours, not the customer's wait. The lead grabs the easy gravy work first, leaving the harder/slower jobs to less senior techs. The customer waiting on a brake job ends up assigned to a B-tech who's slower at brakes — not because the B-tech is bad, but because they don't get reps.
2. It hides talent. The B-tech who's actually exceptional at electrical diagnostics never gets a chance to prove it because the lead is already on it. You're paying for a strength you never use.
3. It is invisible to management. Nobody tracks who got which RO and why. When throughput stalls, there is no data to investigate.

The cost shows up as elevated P90 wait, uneven tech utilization, and a generation of mid-tier techs who plateau because they never get the variety of work that builds skill.

The data-driven way: what the metric actually is

Data-driven routing assigns each incoming RO to the fastest qualified tech currently available, with workload-balance and tech-preference tiebreakers. Three components matter:

1. Average completion time per service per tech

For every (tech × service type) combination you have at least 5-10 historical completions of, you have an average completion time. Tech A averages 19 minutes on a Subaru oil change; Tech B averages 24. Tech B averages 38 minutes on a brake pad replacement; Tech A averages 47. The matrix isn't about who's "better" — it's about who's better at what. Most stores discover their fastest oil-change tech is not their fastest brake tech.

2. Qualification gates

You don't route a transmission diagnostic to a quick-lane tech just because they're free. Every service has a minimum qualification level. Routing only happens within the eligible pool. This is non-negotiable.

3. Workload-balance tiebreaker

If two techs are equally qualified and roughly equally fast on this service (within ~10%), the one with fewer cars on their plate today wins. This prevents your fastest tech from getting buried while everyone else watches.

The result is a routing rule that any modern queue platform can compute in milliseconds, and that mirrors what a really good shop foreman would do if they had perfect memory and weren't pulled into 14 other things.

The speed trap: why fastest-only routing fails

If you implement "fastest qualified" without anything else, two failure modes show up within weeks.

Failure mode 1: corner-cutting

Techs are paid on flag hours and now know they get more work assigned if they finish faster. Some will start skipping the multi-point inspection, half-doing the torque check, missing recalls. Your throughput goes up. Your come-back rate goes up faster. Your CSI craters in three months. Speed without quality is just churn dressed in a number.

Failure mode 2: senior tech burnout

If your senior tech is fastest at everything, they get assigned everything. They eat lunch at their toolbox. They start looking at job listings. By month four, they've left for the indie shop down the road that pays the same flag rate but doesn't smother them.

Both failures are preventable. The fix isn't to abandon data-driven routing — it's to use the right data.

Combined metrics: speed + quality + customer signal

The version of tech performance worth routing on is a composite of three numbers, not just one.

Metric	Definition	How to capture	Weight in routing
Speed	Avg minutes per (tech × service) over last 90 days	RO timestamps, queue platform	~50%
Come-back rate	% of ROs that return within 30 days for the same concern	DMS RO history match	~30%
Customer signal	Avg CSI sub-score on tech-attributable questions	OEM CSI feed or post-visit SMS survey	~20%

The composite score for a given tech on a given service is a weighted blend. A tech who's fast but has high come-back is penalized. A tech who's slightly slower but has zero come-backs and great CSI gets bumped up. The system pays for both speed and quality.

Two implementation notes. First, you only need 90 days of data to start; longer windows are better but the rolling 90 captures recent performance changes. Second, customer signal is hard to attribute cleanly because customers rate "the visit" not "the tech." A reasonable proxy is to attribute the CSI of each RO to its primary tech, then average. Imperfect, but directionally correct.

A worked example with real numbers

Imagine a four-tech express service shop. Below is a fictional but realistic completion time matrix in minutes for the four most common services. (Numbers anonymized from real data.)

Tech	Tenure	LOF	Tire rotation	Brake pads	Battery
Mike (Lead)	14 yrs	22 min	15 min	42 min	18 min
Sarah	6 yrs	19 min	14 min	38 min	17 min
James	3 yrs	21 min	13 min	51 min	22 min
Devon	1 yr	28 min	17 min	58 min	24 min

Under traditional routing — "Mike picks first" — Mike does most of the LOFs and most of the easy batteries. Sarah does whatever's left after Mike. James and Devon get the leftovers. Average customer wait under that pattern: ~34 minutes (P50).

Under data-driven routing, the picture changes. Sarah is actually the fastest LOF tech, and James is the fastest at tire rotations. Mike isn't fastest at anything in this matrix — he's a strong all-around generalist, but he doesn't have the top spot in any single column. That doesn't mean Mike is worse; it means his strength is doing the harder diagnostics that aren't on this menu, which is exactly where you should route him.

So under data-driven routing on a typical 8-hour express shift:

• Sarah gets 60% of LOFs. Avg LOF wait drops 14% because she's faster.
• James gets 50% of tire rotations.
• Mike gets brake pads (he's fastest there) and gets routed any harder diagnostic walk-in.
• Devon gets a balanced mix of LOFs and rotations to build reps, while a workload cap keeps her from being overwhelmed.

Metric	Traditional routing	Data-driven	Change
Avg cars/bay/shift	6.4	7.8	+22%
P50 customer wait	34 min	27 min	−21%
P90 customer wait	74 min	49 min	−34%
Tech utilization variance	22% std dev	9% std dev	tighter
Devon's variety of work	78% LOF only	40% LOF, 35% rotation, 25% other	broader skill

None of these numbers required anyone to work faster. The work was already getting done. It just got distributed more rationally.

How to introduce this without alienating your seniors

This is where most data-driven routing initiatives die. The technology works; the rollout doesn't. Senior techs hear "data-driven" and read "we're going to clip your hours." Three approaches that work:

1. Tie it to flag-hour payouts, not against them

If your senior tech currently makes 55 flag hours/wk under traditional routing, your goal is to make sure they hit at least 55 flag hours/wk under the new system — and ideally more. Show them this commitment in writing before the change. If the routing logic ever causes them to drop below their baseline, you adjust the workload cap or pay them the difference for the rotation period. Their take-home cannot decrease as a result of the change.

2. Roll out in phases

Don't flip the switch on day one. Phase 1 (weeks 1-2): the queue tool shows the recommended tech, but the human dispatcher still decides. Phase 2 (weeks 3-4): the system auto-assigns, but the dispatcher can override with one click. Phase 3 (weeks 5+): full auto-assignment with override available. By phase 3, the team has seen the recommendations make sense for a month and trust is built.

3. Make the data visible to the techs themselves

The biggest cultural shift: techs see their own performance dashboard. Not as a public ranking — privately. Their average times, their come-back rate, their CSI score. Techs love this when it's framed as their data, not management's surveillance data. Senior techs get to see exactly where they're strong and where the data backs them up. Junior techs get a clear path to improvement.

4. Transparent override criteria

If the dispatcher overrides the system's recommendation — say, because Mike has been on a hard diagnostic and needs a "win" — that's allowed. But the override should be logged and visible. This prevents the new system from quietly turning back into the old system because of a few habitual overrides.

5. The senior tech as senior

One of the best moves we've watched: the senior tech becomes the unofficial mentor for the data review. They sit with the manager every two weeks, look at the team's numbers, and weigh in on whether the routing logic is producing good outcomes. Status preserved, ownership shared. The route to senior tech buy-in is treating them like the experienced craftspeople they are, not like nostalgic obstacles.

The downstream effect on retention

The least-discussed benefit of data-driven routing is what it does to retention — for both your great techs and your mediocre ones.

Great techs love being recognized

When Sarah sees that the data shows she's the fastest LOF tech and her CSI sub-score is the highest on the team, that recognition is durable in a way that "good job" from a manager is not. The data is undeniable. It also makes raise conversations easier — for both sides.

Mediocre techs improve

When James sees his tire-rotation time is second on the team but his brake time is 30% slower than the median, he has an explicit improvement target. Most techs want to be good at their job; what they don't always have is clarity about what "good" looks like. The data provides that clarity. Six months in, you typically see the spread narrow as the bottom of the distribution improves more than the top moves.

Bad techs self-select out

This is the uncomfortable part. A small fraction of techs in any shop are not contributing — they coast, they cut corners, they have unexplained gaps in their work logs. Under traditional routing, these patterns are obscured. Under data-driven routing, they become visible to everyone, including the tech themselves. Most either improve or leave on their own. You don't have to fire anyone; the system removes the cover.

Hiring gets easier

Stores that run data-driven routing tend to attract better candidates. Why? Because techs talk. The good ones know which shops have systems and which shops have politics. A tech who's confident in their own work prefers a system. A tech who isn't, prefers politics.

What to do Monday morning

1. Pull the data you already have. RO history with tech assignments and timestamps. Most DMS systems have this. If your platform doesn't capture it, that's the first gap to close.
2. Build the matrix. Tech rows × service type columns × average minutes. Excel is fine. Note where you have <5 data points; those cells aren't reliable yet.
3. Look for surprises. Almost always there are at least two or three "I had no idea X was that fast at Y" findings. Note them.
4. Pull come-back rates and CSI sub-scores. Combine into a composite score per tech per service.
5. Have the team meeting. Walk the team through what you've found. Ask their reactions. Set expectations for the phased rollout.
6. Phase 1. Recommendations only, dispatcher decides. Two weeks.
7. Phase 2. Auto-assign with one-click override. Two weeks. Track override rate and reasons.
8. Phase 3. Full auto-assign. Continue monitoring. Re-build the matrix every 90 days.

Most stores complete this in 60-90 days from "let's try it" to "this is just how we work now." Throughput moves visibly within the first 30 days. Retention effects show up over 6-12 months. The senior-tech revolt that managers fear almost never actually materializes if the rollout is done with care.

The honest summary

Data-driven routing is not a silver bullet. It will not fix a parts problem, an advisor handoff problem, or a culture problem. What it will do is take the single most arbitrary decision in your service department — who works on which car — and make it consistently better than what gut feel can produce. The tools are cheap. The data is already in your DMS. The remaining ingredient is the willingness to manage from numbers instead of habits.

For more on the throughput math behind this, see our deep-dive on bay throughput. For the customer-facing implications of better routing, see the psychology of waiting.

Related reading: Bay throughput: the metric that separates good service departments from great ones · 5 metrics every service manager should review every Monday morning