Every service company eats callbacks. The water heater that leaks again, the camera that drops offline a week after install, the drain that was never really cleared. The work gets redone, the margin quietly disappears, and at the end of the year nobody can say what callbacks actually cost or who they cluster around.
Service Fusion holds the jobs. It just does not know which ones are callbacks. Here is the fix I use, and the reporting math that makes it fair.
One custom field does the linking
A callback is only meaningful in relation to the job that spawned it. So the fix is a custom field on the job: is this a callback, and if so, what was the original job number.
That is the whole mechanism. When the office creates a return-visit job, they fill in the original job’s number. The Service Fusion API can read custom fields, so the nightly sync that already feeds the dashboard picks it up, and suddenly every callback in the system points at its parent job.
From there, reporting gets honest. Callback rate by month. Callback rate by tech. Which job types generate the rework. What the redo hours actually cost. All from one field the office fills in at job creation.
The math most companies get wrong
Here is the part I care about, because it decides whether techs trust the number.
Say a tech installs something in January and it fails in March. Which month has the callback? Most quick reports say March, because that is when the return job was created. That is wrong twice. It hides the January quality problem, and it dings whoever was on the schedule in March for work they did not botch.
The honest version attributes the callback to the original job: January’s month, January’s tech. The custom field makes that possible, because the link back to the original job carries its date and its tech with it. On the dashboard, a callback shows up where it belongs, and a tech’s rate reflects their own work and nothing else.
Techs argue with unfair numbers. They mostly stop arguing with fair ones.
Start now, because you cannot backfill
The one hard truth about this setup: the data starts the day the field does. If the field did not exist in January, there is no recovering January. I have built this for a client and watched the first weeks of data trickle in, and the temptation is to call it useless because the history is empty.
It is the opposite. Six months from now, the six months of truth exist only if the field started today. Callback tracking is one of those systems where the best time to start was a year ago and the second best time is this week.
What it looks like on the dashboard
On the dashboards I build, callbacks get a small, permanent home: rate by month attributed correctly, the list of open callbacks, and cost of rework where labor data supports it. It sits next to profit by job and stuck jobs, the other numbers owners actually run on. The broader reporting setup is covered in getting real reports out of Service Fusion.
Setup is small. A custom field, a definition everyone agrees on for what counts as a callback, and a sync that reads it. If your company runs on Service Fusion and callback cost is a shrug today, this is one of the highest-value low-effort fixes I know. The rest of my Service Fusion work is on this page, or book a call and we can talk through your setup.