How to build a maintenance tech bonus plan tied to real metrics

A bonus paid on work orders closed is a bonus paid for closing work orders, which is not the same as fixing things.

Techs are rational. If closure count pays, closure count goes up, and callbacks go up with it because a fast close that does not hold still counts.

Any single-metric plan gets optimized against

Worth walking through the failure modes, because each one is something a reasonable person would do.

Pay on closures and people close prematurely and reopen as new work orders.

Pay on speed and people take the easy tickets first and leave hard ones aging.

Pay on resident satisfaction survey scores and people ask residents to rate them well, which is not fraud, it is just how humans respond to a survey they are graded on.

Pay on turn time alone and preventative maintenance stops getting done, because nobody is measured on the thing that prevents next year's work order.

None of these are bad-faith responses. They are correct responses to the incentive as written.

Four weighted components, so gaming one degrades another

Four components, weighted. The specific weights matter less than having more than one.

Completion rate, 30%. Percentage of assigned work completed in the period. Keep it: 40+ properties in the reference portfolio run at 100% closure and that is a real standard worth paying for.

Callback rate, 30%, inverted. Lower is better. This is the component that makes the first one honest, because closing badly raises completions and raises callbacks together.

Turn time, 25%, measured on the property rather than the individual. Make-ready is the maintenance work that lands directly in NOI, and it is genuinely a team output. A tech cannot control a turn alone, so paying them individually on it either rewards luck or encourages them to grab turn work over resident tickets.

High-risk workflow compliance, 15%, as a gate rather than a slider. Not how many were completed. What share were completed with required photos and approvals attached. Treat it as pass or fail: below threshold, the rest of the bonus does not pay. A high-risk work order closed without documentation is a liability that looks like a completed task.

Use the property's own prior period as the benchmark

The single most common design error is comparing techs across properties.

A 1966 Class C asset generates different work than a 2025 lease-up. A tech at the older property will have worse numbers on almost every metric, and paying on that is paying for building age.

Benchmark each property against its own prior period. That measures improvement, which is the thing you actually want, and it removes the argument about whether the comparison is fair.

Make the numbers visible before they are payable

A bonus plan announced with metrics nobody has seen is a plan people distrust.

Run the numbers visibly for a quarter before a dollar depends on them. Two things happen. Techs check their own figures and find the errors, which there will be. And you find out whether your data is good enough to pay on, which for callback rate specifically it often is not at first.

GetDone has a per-technician My Analytics view for this: the tech sees their own open, new, active, and completed work, their callbacks, and their breakdown by type. Self-visibility does more for behavior than a monthly review does, and it also means nobody is surprised.

Adoption is the precondition, not a detail

None of this works if techs do not log the work.

94% of maintenance techs at ResProp use GetDone, and that is the number that makes a metrics-based bonus possible at all. A plan built on partial logging pays whoever documents most rather than whoever performs best, which is the worst possible outcome: it is unfair and it teaches paperwork.

The other end of that distribution: our lowest-adoption property sits at 46%. You could not run this plan there yet, and pretending otherwise would produce a bonus cycle that damages trust.

What a bonus plan cannot fix

If base pay is below market, a bonus is a retention patch on a compensation problem and techs will read it that way.

If a supervisor is the reason people leave, a well-designed bonus does not help.

And if the plan's total value is small relative to base, it will change measurement behavior more than it changes work behavior, which is the worst of both outcomes: you get the gaming without the motivation.

Check that the metrics you would pay on are ones you currently trust. Which of the four do you not have clean data for?