How do I tell a real callback from a genuinely new problem at the same address?
Use three tests together: time since the last visit, whether the complaint matches the prior work, and whether the same component or system is involved. A return within a short window, on the same component, with the same symptom, is a callback. A different system, or the same system after a long interval, is new work. Write the rule down and enforce it in software, not in each dispatcher's head.
Why this is a data problem before it is a quality problem
Every shop tracks callbacks and almost none of them can defend the number. The reason is that the classification happens at booking, by whoever answers the phone, using judgment that varies by person, mood and how busy the morning is. When a technician's callback rate is used in a performance conversation, the first thing that surfaces is that the definition was never consistent.
Fixing the definition costs nothing and changes the meaning of every downstream metric that touches it.
A three-test rule that holds up
The third test is where most disagreement lives, so give it an explicit escape hatch: a disputed state that a manager resolves weekly. Metrics with an honest unknown bucket survive scrutiny; metrics that force every case into a binary do not.
- Window. Pick an interval per trade and hold to it. Repair work commonly uses a short window; installs use a longer one. The exact number matters less than that it is the same number every time.
- Scope match. Same equipment, same system, same component as the prior visit. A furnace call two weeks after a water heater install is not a callback no matter how close the dates are.
- Symptom match. The customer describes the same failure, or a failure plausibly caused by the prior work. A new, unrelated symptom on the same unit is a judgment call — flag it for review rather than silently counting it either way.
Where the classification should live
Not in a free-text note. It needs a structured field with a fixed set of values, linked to the originating job, so that a callback can be traced to the visit that caused it. Most field service platforms can carry this through a job type, tag or custom field — the choice matters less than picking one and using it exclusively.
Once it is structured, it can be joined to technician, job type, equipment age and parts used, which is where the actionable patterns are. Getting that linkage out of the platform and into a reportable shape is standard field service integration work.
What the classified data is actually for
Three things, in this order. First, capacity planning — callbacks consume board hours you already sold. Second, training — callback clusters by job type or failure mode point at a specific skill gap, not at a person. Third, coaching, which is a human conversation informed by the record.
That last point matters. The data should show a manager what happened and let them decide what it means; coaching support exists to make the conversation better informed, not to render verdicts about people.
Topics: callbacks · warranty · quality · data quality
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.