Incident Reports: Writing Them So They Get Used

Most businesses have a folder of incident reports that nobody has opened since the day each one was filed. The form was completed because somebody insisted, the detail was thin because it was the end of a shift, and the record now exists without being useful to anyone. An incident report has one job, which is to make the next incident less likely, and a filed report that cannot be compared to anything does not do it.

What belongs in one

Field	Why it is there
Sequence of what happened	The account, in order, without interpretation
Time, date, exact location	Lets you match it against other records
People involved and present	Witnesses fade from memory within days
Immediate action taken	Separates the response from the cause
Category, from a fixed list	Makes patterns countable later
What would have prevented it	The reporter usually knows and is rarely asked

The prevention field is the one most forms leave out, and it is the cheapest source of improvement a business has. The person who was standing there generally has a view, it takes ten seconds to record, and nobody asks for it.

The category field is the one that decides whether you can ever count anything. Free text means no patterns; a short fixed list, five or six options, means you can ask how many of these happened on night shifts and get an answer.

Let people speak

Typing a report at the end of a physical shift loses to going home, reliably, and the result is the thin account you have in the folder. Describing what happened out loud for ninety seconds does not.

Capture the audio, transcribe it, have the transcript organised into your fields, and hand it back for correction. People are far better at fixing a wrong detail than at producing a complete account from nothing, and the corrections are where the substance arrives.

Check the names, times and equipment identifiers, because transcription fails on exactly that vocabulary, which is the problem described in where automatic transcription falls short.

Keep cause out of the report

The report records what happened. Working out why is a separate activity with different people and more time, and merging the two produces a document that reads as an accusation and gets written defensively.

This matters particularly when a model is structuring the account, because asked for a cause it will supply one that sounds reasonable and is not supported by anything in the description. Keep the fields descriptive and do the analysis afterwards, which is set out in root cause analysis.

Near misses are the better record

A near miss has the same causes as an incident and none of the cost. A business that captures them gets to fix the mechanism before anybody is hurt, which is the entire argument for bothering.

The obstacle is cultural. People report near misses while doing so has never once been followed by blame, and they stop permanently after the first time it is. One manager reacting badly to one report ends the programme, usually without anyone realising it has ended.

Say explicitly what reports are used for and what they are not used for, and then behave consistently with it for a year. There is no shortcut and no software that substitutes for it.

The pattern is the point

One report tells you about one event. Forty reports tell you that the same category keeps appearing at the same location on the same shift, which is a finding you can act on and which no individual report contains.

Reading across them is well suited to automation: clustering by category, by location, by time of day, and flagging the combinations that recur. The output is a shortlist for a person rather than a conclusion, and the same sampling caution applies as anywhere else, as in quality assurance when AI writes the first draft.

Put the count somewhere visible monthly, broken down by category rather than as a single number, since a total tells you nothing about what to fix. A simple dashboard is enough.

Close the loop out loud

Whoever filed the report should hear what happened as a result, even when the answer is that nothing changed and here is why. Silence after a report teaches people that reporting is paperwork, and that lesson takes a long time to unlearn.

Where a report leads to a change in how work is done, update the procedure at the same time rather than later, which is the maintenance habit in checklists that hold up and standard operating procedures. In field work the same capture discipline applies to job notes, covered in field service software.

Frequently Asked Questions

What should an incident report include?

What happened in plain sequence, when and where, who was involved, what was damaged or injured, what was done immediately, and what the person reporting believes would have prevented it. That last field is the one most forms omit and the one that makes the record useful later, because the person at the scene usually knows and is rarely asked.

Why do incident reports stop getting filed?

Because filing one costs the reporter more than it returns to them. A long form at the end of a shift, with no visible consequence afterwards, teaches people that reporting is paperwork. The two fixes are making capture take under two minutes and closing the loop visibly, so the person who reported something sees that it led somewhere.

Can AI write incident reports?

It can turn a spoken account into a structured record, which is the part that blocks reporting. Someone describes what happened for ninety seconds, the transcript is organised into your fields, and they correct it. What it should not do is infer cause or assign fault, because neither is in the account and a model asked for them will produce a confident answer anyway.

Should near misses be reported?

Yes, and they are the more valuable record. A near miss has the same causes as an incident without the cost, so a business that captures them gets to fix mechanisms before anyone is hurt. The obstacle is cultural rather than procedural: people report near misses when doing so has never once been followed by blame, and stop permanently after the first time it is.

How long should incident records be kept?

Long enough to show a pattern, which is usually several years, and in some sectors retention periods are set by regulation or by your insurer. Check what applies to you rather than choosing a number. Keeping them searchable matters as much as keeping them, since a record nobody can retrieve during an investigation is functionally absent. This is general information rather than legal advice.