Incident reports that still make sense six months later

An incident report has an unusual property: it is written quickly, by someone tired, and read carefully, by someone with time and a reason to scrutinise it. That asymmetry is the whole design problem.

What makes a report fail later

• –Time recorded vaguely — "during the night" rather than a time
• –Conclusions written instead of observations — "he was aggressive" rather than what was said and done
• –Missing sequence — outcomes recorded without the steps that led to them
• –No record of who else was present, so accounts cannot be corroborated
• –Photographs taken on a personal phone and never attached to anything

None of these are failures of honesty. They are failures of structure — an officer given a blank box will write a summary, because a blank box invites one.

Structure does the remembering

A form that asks specific questions gets specific answers. Asking for a time, a location, who was present and what was observed produces a materially different record from a free-text field headed "details".

• –Capture on shift, while the detail is still available
• –Separate observation from interpretation, and ask for both
• –Attach photographs to the record at the point of capture, not later
• –Track the report through to close-out, so outcomes are on the same record

The client's copy

Clients usually want a version of the same event. Writing it twice invites the two versions to disagree, which is worse than either version alone. Generate the client's copy from the same record. See what to send a client, and how often.

Written for the reader who was not there

An incident report is written by someone who was present, and read — sometimes years later — by someone who was not, possibly in a context where it matters a great deal. That gap is where most reports fail. Shorthand that made sense on the night, assumptions about what the reader knows about the site, and judgements recorded as facts all become problems when the report has to stand on its own.

The practical test is whether someone unfamiliar with the site could reconstruct what happened, in what order, from the report alone. Most reports do not pass it, and the fix is mostly discipline about time, sequence and specificity rather than length.

Written at the time, not at the end of the shift

The other recurring weakness is timing. A report written at the end of a shift compresses events and loses the sequence, and a report written the following day loses more. Contemporaneous notes — even rough ones, timed — are what make a later report credible, and they are the thing most often missing.

Common mistakes

• –Writing up at the end of a shift rather than contemporaneously
• –Shorthand and site jargon a later reader cannot interpret
• –Recording conclusions rather than observations
• –No clear sequence of times, so the order of events is ambiguous
• –Omitting who was notified, when, and what they said
• –No record of what was done afterwards, so the report ends mid-story

What separates a report that stands up later

Contemporaneity and specificity, in that order. A rough note written at the time, with times against events, beats a polished account written the next morning — and an account that distinguishes what was observed from what was concluded beats one that presents inference as fact.

The practical enabler is making it easy to capture something immediately, on whatever device an officer has, rather than requiring a form to be completed at a desk at the end of a shift. The quality difference between those two is larger than any amount of training on report writing.

One practical test: give a report to somebody who was not there

Take a recent incident report and hand it to a colleague with no knowledge of the site. Ask them to describe what happened, in order, and what was done about it.

Where they cannot, the report will not support the contractor in two years either — and that is the only moment it matters. Site shorthand, assumed knowledge and conclusions recorded as facts are the three things that consistently defeat this test.

• –Write for a reader who has never seen the site
• –Record observations rather than conclusions
• –Put times against events so the sequence is clear
• –Record who was notified and when
• –Capture contemporaneous notes, not an end-of-shift write-up