First-time fix rate: the formula, and why the benchmark is a trap

First-time fix rate = (jobs closed on visit 1 / total jobs) x 100

The formula, and the part that goes wrong

The arithmetic is easy. 212 jobs, 174 closed on the first visit, and you are at 82%.

The definitions are where it falls apart. Three teams using that same formula will report three different numbers, because they disagree about what belongs in it. A rate that moves from 71% to 78% because somebody quietly changed a definition is worse than having no rate at all, because people will act on it.

Settle these three before you measure anything:

• The technician diagnosed the fault but came back to fit a part. Not a first-time fix. The customer still waited twice.
• The customer was out and nothing was attempted. Not a job. Counting it drags the number down for a reason that has nothing to do with the work.
• An installation always planned across two days. Not a failure. Exclude it.

Write your answers down somewhere the whole team can see. The definition matters more than the number, because the definition is what makes two months comparable.

Why there is no benchmark worth quoting

"What is a good first-time fix rate" is one of the most searched questions in field service, and nearly every answer gives a percentage with no source attached.

We are not going to add another one. A team swapping filters on a known appliance model should expect a far higher rate than one diagnosing intermittent faults in twenty-year-old heating systems. Both numbers are real. Comparing them tells you nothing about either team.

Your own number, measured the same way for six months, is the only comparison that holds. If it is going up, whatever you changed worked.

The twenty-job diagnostic

This is the part worth doing, and it takes about twenty minutes.

Take your last twenty repeat visits. For each one, write down which of these caused it:

1. No part. The technician arrived without what the job needed.
2. No access. Locked gate, wrong code, nobody in, waiting on a security desk.
3. No history. The previous visit's notes were in someone's head, or in a thread nobody can search.
4. Genuinely two-visit work.

Then count.

If category 1 is more than four of your twenty, the booking call is not capturing enough to predict the part. That is fixed by changing what you ask, not by training technicians.

If category 2 appears at all, it is almost certainly undercounted. Access failures get recorded as something else — the technician writes "could not complete" and the real reason disappears. No fix happens from the car park.

If category 3 appears more than twice, your second visit is repeating the first visit's diagnosis. That is pure waste, and the cheapest of the four to eliminate.

What to change first

Categories 2 and 3 are information problems, and they are the ones software actually solves. The access code from last time, the note that reception needs ID, the previous technician's diagnosis — all of it should travel with the job rather than with the person who took the call.

Category 1 is a process change. Add two questions to the booking script and watch whether the number moves over the following month.

Start with whichever bucket is largest. Most teams guess wrong about which that is, which is exactly why the twenty-job count is worth more than any benchmark you could borrow.

OkPilot keeps job history, access notes and proof attached to the job itself, so a second visit never starts from nothing.