The Service Report That Actually Gets Read
Why this matters
Most service reports are written to satisfy a form, not to be read. Techs fill in a field, hit submit, and move to the next job. Then six months later a callback happens, or a customer disputes a charge, or a new tech shows up on a repeat visit with zero context, and the report that was supposed to help nobody actually helps. A report that gets read protects the shop, speeds up the next visit, and often closes an upsell the tech didn't have time to pitch in person.
Who actually reads it, and when
A service report has three different readers, at three different times, wanting three different things:
- The customer, today. Wants to know what happened and why they're being charged what they're being charged.
- The next tech, months from now. Wants to know what was already tried, what parts are in the unit, and what to check first.
- The owner or office staff, at dispute time. Wants proof of what was found, what was disclosed, and what the customer agreed to.
Write for all three, not just the one in front of you. A report that only satisfies the customer today ("fixed the issue") gives the next tech nothing and gives the owner no defense later.
The four things every report needs, in order
- What was reported. The customer's words, briefly, not your diagnosis. "Customer reported no hot water since Tuesday." This anchors the report to the actual complaint and matters if the complaint changes later.
- What was found. Your observation, specific and measurable where possible. Not "unit not working," but "pilot light out, thermocouple tested at 2mV, should read above 20mV."
- What was done. The actual action taken, in plain verbs. "Replaced thermocouple. Relit pilot. Verified hot water at two fixtures."
- What's next, if anything. Follow-up needed, a part on order, a recommendation declined, or a clean "no further action needed."
Skipping straight from "reported" to "done" without the "found" section is the single most common failure. It's the middle section that protects you and informs the next tech.
Specific beats generic, every time
| Generic (useless later) | Specific (useful later) |
|---|---|
| "Checked system, all good" | "Verified static and operating pressures within manufacturer range, no leaks found at accessible joints" |
| "Replaced part" | "Replaced failed capacitor, tested run amps post-repair at 4.2A against a 5.5A nameplate rating" |
| "Customer declined repair" | "Advised customer that the secondary drain line was clogged and posed an overflow risk; customer declined the flush, opted to monitor" |
| "No issues found" | "Ran full diagnostic cycle, no fault codes, system cycled twice with normal temperature differential" |
The specific version takes maybe ten more seconds to type and is the difference between a report that holds up and one that doesn't.
Write the recommendation even when it's declined
A declined recommendation, undocumented, looks identical to a recommendation that was never made. If you noticed something worth flagging but the customer said no, write it down anyway, in one sentence, with the customer's response. This is not about covering yourself for its own sake, it's the only record that exists once you've left the property. See related: Documenting a Customer Refusal the Right Way.
Keep it in plain language, not shorthand only you understand
Field shorthand is fast to write and useless to anyone but you. "Cap bad, swapped, good now" tells the next tech nothing about which capacitor, what reading, or what "good" means. Expand the shorthand into a sentence a stranger could follow. If you must abbreviate, use terms that are standard across the trade, not personal habits.
The one-line summary at the top
Busy readers, especially customers and dispatchers triaging a callback, often only read the first line. Put a one-sentence summary at the very top of the report, above the detail: "Diagnosed and repaired failed capacitor, system verified operational." Everything below supports that line. A report with no summary forces every reader to reconstruct the outcome from the detail, every time.
What to leave out
A good report is specific, not long. Skip narrating your own effort ("worked hard to diagnose this tricky issue") and skip restating information already in the job record (customer address, appointment time). The report exists to capture what only you, standing at the equipment, could observe. Everything else is noise that pushes the useful parts further down the page.
References
- See related: Documenting a Customer Refusal the Right Way
- See related: Documenting an Unsolved Fault for the Next Tech
- Trade-standard practice for field service documentation