Revenue per Technician Credits the Same Job Twice

Why this matters

Revenue per technician is built by summing each job's revenue against every technician assigned to it. A job with two names on it credits both of them the full amount. The figure does not split, so the column adds up to more than the shop's revenue whenever any job carried a second technician, and the excess lands entirely on whoever rides along on the big work. This is an attribution problem, not a performance measure, and it gets used for bonuses.

The double credit, and how large it is

One month at a four-technician shop. 62 completed jobs with revenue, and the shop billed 168.0 units, indexing revenue so 1.0 unit is one standard service call.

• 44 jobs ran solo and carried 96.0 units between them.
• 18 jobs ran with two technicians and carried 72.0 units, which is 4.0 units each. (Holding the two-tech jobs at a uniform size keeps the arithmetic below readable; nothing in the argument depends on it.)

The per-technician column:

The column sums to 240.0 units against a shop that billed 168.0. The excess of 72.0 units is exactly the two-tech revenue, counted a second time, and it is 42.9 percent of the month's revenue appearing twice.

The reconciliation check

Run this before anybody reads the column, and it takes one division.

Sum the column and divide by the revenue on the same completed jobs, not the period's invoiced total, which carries tax, deposits and work closed in other periods. Here, 240.0 over 168.0 is 1.43. Any value above 1.00 means multi-assignee jobs exist in the period and the column is not a division of revenue, so no share, percentage or rank taken from it means what it appears to mean.

One trap in that check: a job completed with no technician assigned contributes to the shop total and to nobody's column, which pulls the ratio down. A period with a few unassigned jobs and a few two-technician jobs can land close to 1.00 by cancellation while both problems are present. So pair the ratio with a count of jobs by number of assignees:

That table is the actual answer. The ratio is a fast screen, and it can lie; the count cannot.

It also lets you compute the inflation without rebuilding the whole column. A job with k names credits its revenue k times, so it contributes (k minus 1) times its own revenue to the excess. Sum that across the period and you have the overcredit exactly:

• 18 jobs with 2 names, at 4.0 units each: (2 minus 1) times 4.0, eighteen times, is 72.0 units.
• Nothing with 3 names, so nothing further.

Total excess 72.0 units, which is what the column showed. A single three-technician install would have added twice its own revenue rather than once, so a shop that regularly crews three deep inflates its column faster than the job count suggests.

One more thing the count table cannot tell you: whether the assignment record is true. A name left on a job after a reschedule, a second technician assigned and then pulled, or an apprentice who attended with no assignment recorded all corrupt the column at the source. The check is to compare assignments against time logged per person per job. A name assigned to a job with no logged time on it is either a stale assignment or unrecorded attendance, and both need fixing before any credit rule is worth applying.

One month, three ways

Take the same 62 jobs and the same 168.0 units, and apply each of the three credit rules.

Under split credit, each of the 18 two-tech jobs gives 2.0 units to each name, so B's 14 of them yield 28.0 units rather than 56.0. Under solo-only, the two-tech jobs are dropped entirely.

Now read the orderings:

• Full credit: A, B, D, C.
• Split evenly: A, D, B, C.
• Solo jobs only: D, A, C, B.

Three rules, three different orderings, one month, four people, no disagreement about a single number anywhere. B finishes second, third and last. D finishes third, second and first. If a bonus is paid off this column, the rule you never wrote down decided who got paid.

Notice also what the two extreme methods do with the same 72.0 units: full credit counts them twice, solo-only ignores them completely. The revenue the first method double-counts is exactly the revenue the second one throws away, which is 42.9 percent of the month either way.

What the wrong use costs, beyond the wrong answer

Say the shop pays a bonus to the top two on this column. Under full credit that is A and B. Under split it is A and D. Under solo-only it is D and A. B is paid under exactly one of the three rules, and nothing about B's month differs between them.

The money is the smaller half of the damage. The crew works out the rule faster than the office does, and once they have, the rational move is to get added to the large jobs rather than to run the small ones well. A per-person metric with an unstated split rule does not just measure the wrong thing, it teaches the crew to manage the assignment instead of the work. In this month that means competing for the 18 two-technician jobs, which are 29.0 percent of the job count and carry 42.9 percent of the revenue, and quietly avoiding the 44 solo jobs that are the rest of the business.

Normalising the column does not rescue it either, and this is the most common attempt. Divide by days worked to be fair to a part-timer and A, at 78.0 units over 22 days, reads 3.55 units a day while B, at 64.0 over 18 days, reads 3.56 - indistinguishable. On split credit the same two read 54.0 over 22, or 2.45, against 36.0 over 18, or 2.00, which puts B about 18 percent below A. A correct denominator applied to a double-counted numerator does not repair the attribution, it launders it, because the result now looks like a rate rather than a total and invites even more confidence.

The honest alternatives

Split credit evenly among assignees. Each of k names on a job takes revenue over k.

For it: the column sums to the revenue of assigned jobs, so shares are real and comparable, and no job is invisible. Against it: it assumes equal contribution, which is wrong whenever a lead and a helper run together. It inflates the helper and deflates the lead, and this data shows it - B moves from last on solo work to third on split, entirely on the strength of riding along on work someone else led.

Count only jobs with exactly one assignee. Drop the rest.

For it: no attribution assumption at all. Every number is a fact about work that one person did. Against it: the discarded population is not random. Big and complex jobs are precisely the ones that carry a second name, so what survives is systematically the smaller, simpler work, and a technician who rarely works alone barely gets measured. B's entire solo record here is 6 jobs and 8.0 units, which is too little to say anything about anybody.

A third option, where the data supports it: split by logged hours on that job rather than evenly. It reflects actual contribution and needs no assumption about roles. It also requires per-person time logged against every job, and it hands more credit to the slower technician, so it trades one distortion for another. Use it only if your time records are good enough that you would defend them in front of the crew.

There is no rule that is right in general. There is only a rule you state, apply to every period the same way, and name every time you show the column.

A default to start from and tune: where jobs with two or more assignees carry under 10 percent of the period's revenue, use solo-only and accept the loss of coverage; at or above 10 percent, split evenly and label the column "split credit" everywhere it appears. Unit of analysis is revenue on completed jobs, summed per period, because what the rule trades away is money rather than headcount. In the worked month the 18 two-name jobs are 29.0 percent of the count and 42.9 percent of the revenue, so this shop is firmly in split-credit territory and the full-credit column should not leave the office at all.

Whichever you pick, publish the reconciliation ratio beside the column. A column labelled with its rule and printed next to a ratio of 1.00 is a number a crew can argue with productively. A bare column is one they will argue with anyway, and they will be right.

What it is genuinely good for

Once you stop reading the full-credit column as performance, it answers questions nothing else does, because it is a record of who was on what.

• Who is never on the big work. Compare each technician's solo revenue per solo job. B runs 8.0 units across 6 solo jobs, which is 1.33 units a job. D runs 41.0 across 15, which is 2.73. B's own work is half the size of D's, while B is on more two-tech jobs than anyone. That is the signature of a helper, and it is a development question, not a productivity one.
• Which pairs run together. Each of the 18 two-tech jobs has two slots. A is on 12 of them, so A is absent from 6; B is on 14, so B must share at least 14 minus 6, or 8 jobs with A - nearly half the two-technician work in the month. Useful for scheduling, for cross-training, and for knowing whose habits are being taught to whom.
• Whether crewing is drifting. Track the share of jobs with two or more assignees over time. Where it climbs, the shop's effective capacity is falling even though headcount is not, and this column is where it becomes visible first.

The general rule

This is a specific case of something worth carrying to every per-person figure you build: any metric that divides a shared thing among people has to state its split rule before the numbers mean anything, and the same rule has to govern the numerator and the denominator.

Jobs per technician has it. Callbacks per technician has it, and worse, because when a two-technician job comes back it is not obvious which name the callback belongs to, and the convention you pick determines the answer. Revenue per vehicle has it whenever two trucks attend. Hours per job has it whenever the hours come from more than one person.

The test for any of them is the same division you ran above: sum the per-person column and compare it with the total of the shared thing that column divides, measured over the same jobs. If the two do not agree, you have a rule you have not written down, and it is making decisions for you.

References

• See related: Gross Margin Percent Is an Average of Averages - the other place a headline figure is built on a basis nobody states
• See related: Trip Yield: The Number That Prices a Truck Roll - the same warning against per-person use, from the dispatch side
• See related: Setting a Target for a Metric Without Inviting the Wrong Behavior
• See related: A Metric That Doesn't Change a Decision Isn't Worth Tracking