Keeping an Incident Log

What Is the Problem?

Three scenes.

Errors get fixed and forgotten

A wrong figure turns up in an output. Someone spots it, corrects it, moves on. Nobody writes it down. A few months later the same kind of error appears and nobody knows it is a repeat. Learning never accumulates.

Nobody knows where the errors cluster

Checking gets spread evenly across everything. Yet errors concentrate in particular jobs. Without records that concentration stays invisible, so the checking goes to the wrong place. Risky work runs unchecked while ordinary work gets over-reviewed.

The learning stays with one person

An employee learns which jobs need care. But that knowledge sits in their head. When they leave it goes with them, and the next person makes the same mistakes. The organisation pays for the same lesson twice.

Why Does It Happen?

Three reasons.

The word incident sounds too big

People hear incident and think catastrophe. A wrong figure or an inappropriate sentence does not seem to qualify. Yet those are exactly what deserve recording; the big failures get remembered anyway. The value of a log lies in the small and repeating ones.

Recording feels like blame

If writing something down means being held to account, nobody writes. The team hides errors instead. A log has to be built as a learning tool rather than a punishment, and the first entry sets the tone.

Nowhere to write it

If no place is defined, no record gets kept. A complicated system produces the same result; nobody opens it. A shared document is enough, provided everyone can reach it.

How Is It Done?

Three steps.

Step 1: fix a three-line format

Three things get written for every incident. What happened? Where was it caught? What was done? Nothing more is needed. Writing takes two minutes, which is why it actually happens. Ask for a long form and no record gets kept at all.

Step 2: keep the definition broad

What deserves recording is not the major failure. Every output that needed correcting is an incident. A wrong figure, an invented source, a customer message written in the wrong tone. A broad definition fills the log; a narrow one leaves it empty and useless.

Step 3: read it quarterly

Every three months, read the entries. Where is the concentration? Move the checking there. Half an hour of reading shows where the effort should go, and data replaces guesswork. The verification routine gets updated from this reading, and the tool matching gets corrected with the same data.

How Long, Where to Start?

Two minutes per entry, half an hour per quarter.

A few hours a year in total

Each entry costs two minutes. The quarterly reading costs half an hour. That comes to a few hours a year. In return you know which work is risky from evidence rather than assumption.

The return is checking that lands in the right place

Without records, checking spreads evenly and proves insufficient everywhere. With records the risky work becomes visible. The checking concentrates there and lightens elsewhere, so the total load does not rise.

First step: write it looking backwards

Have you corrected anything in the past six months because of an AI output? If yes, your first entry is ready. Write down what you remember. An incomplete record beats no record, and the first line is always the hardest.

The Common Mistake

Three traps.

Turning the log into a punishment

If the question becomes who made the mistake, the log dies. The question should be how it was caught and how it gets prevented. Talk about the process, not the person. A blame culture ends the log; a learning culture feeds it.

Recording only the major incidents

Major incidents get remembered anyway. The value sits in the small and repeating ones. If those go unwritten the pattern stays invisible, and without a pattern the checking has no direction.

Not reading the log

A log that gets kept but never read does nothing. Without half an hour a quarter it turns into an archive. Unread data produces no decisions, which is why a calendar reminder matters.

Frequently Asked Questions