Service call report: a root cause nobody checked
Published
What the tool produced
A technician finishes a service call and asks an AI tool to draft the service call report. He feeds in what he remembered: the unit, the fault, the arrival time. The tool fills in the rest.
The report shows a spare part number, the date of a previous service, an exact model and an action that was done. Some of the details were never given to the tool. It filled them in with full confidence.
This is a failure of the silent completion type. The result is a report that reports an action that was not done.
Why it looked right
The report is readable and tidy. Every field is full. A manager who takes a quick glance at the report sees a complete form, and no empty field that raises a question.
This is exactly the difference between a human report and a completed one. A technician who does not know the part number leaves the field empty. A tool fills it in. So a full field is not proof.
The root cause is also written easily. The tool suggests a plausible cause, and it looks like a diagnosis. Nothing in it signals that nobody checked it.
What happens after the signature
A service call report is closed, and the order closes with it. When it says "fixed" with no root cause, the next call to the same unit is a recurring fault.
A familiar description from a service contractor's ad: the same fault returns three times, because the technician wrote "fixed" with no reason. And the customer is counting.
With a report completed by a tool, the consequence is sharper. Whoever reads the report tomorrow will rely on a part number, a date and an action that nobody verified.
How the engineer catches it
The tool can draft. It cannot invent facts. The short instruction that separates them is: do not invent, write missing.
An item the tool marked as missing is a correct result. An item filled in without a source is a failure. This is a fixed rule, and the technician needs to know it before he opens the tool for the first time.
Every request to the tool has six parts: role, context, task, constraints, source and the missing-data instruction. The context specifies which values were measured in practice and which were not.
There is also a simpler way. The technician writes the report himself, and the tool only improves wording, language or translation. This is use level two, editing, and it requires a declaration only.
A technician who stands facing a manual in English at two in the morning is exactly the person who will turn to the tool. So the instruction needs to be short, clear and available to him on the spot.
The check to run
The work order has three fields: source, value checked, and who checked. Fill them in for every part number, date and action that is reported.
- Compare the part number to the catalog or the manufacturer manual.
- Compare the date and the action to the record: the service log, the maintenance management system or the field documentation.
- Check that the root cause was written by whoever checked it, and that there is evidence for it.
- Record one of four results: match, gap, not verified, missing.
An item with no record is blocked, and marked not verified. The report stays a draft until someone completes it from the source, or leaves the field empty.
The gate rule applies here in full: one blocked item holds the whole report as a draft. There is no partial verification.
Why you do not pass such a report on
A deliverable may be signed only when every item in it has a check or a missing mark. A service call report is a commitment: it goes to the customer and to the organizational system.
So the check is done before the handover, and not after. A report that was passed on without a check is much harder to fix. After the handover the report is already a source that others rely on.
How to bring this into the organization
The expected objection of technicians is that they will not fill in another form. So the fields go into the existing work order template. No new form is opened.
The rollout runs in five steps, in a fixed order.
- Mapping: which deliverables are signed, and who signs.
- Tagging: every deliverable gets a tool use level, in writing, with an approver.
- Embedding: the fields go into the existing templates.
- Training: a workshop on the organization's own deliverables, ending with a quiz without the tool.
- Measurement: once a quarter you check which failure types repeat, and in which deliverables.
Training is step four, and not step one. It first requires the list of deliverables and the tagging table.
Self-check
- Was every part number in the report compared with the catalog or the manual?
- Were the date and the action compared with the record?
- Did the request to the tool include the instruction: do not invent, write missing?
- Was the root cause checked by a person, and not only drafted?
- Did a field that was not supplied stay empty?
- Is it recorded who checked each item?
- Did the fields go into the existing template and not into a new form?
- Do you check once a quarter which failure types repeat?
To practice on your own service call reports: AI for maintenance management.