An internal system fails: the order tool will not open, a nightly import duplicates records, a shared mailbox stops forwarding. Someone fixes it, work resumes, and by Friday nobody mentions it. Three months later the same thing happens again, and again nobody remembers what helped.
A short written review after the incident prevents this. It does not need a meeting series or a special tool. One page, written within a few days, is enough for a company of any small size.
What counts as an incident
Set a low threshold, otherwise reviews will never happen. A reasonable rule: write a review whenever an internal system was unavailable or wrong long enough that people had to stop work, redo work or correct data. A fix that took ten minutes still counts if three colleagues lost their morning.
Do not review everything. A single slow page is a note in the task list, not an incident.
Blameless does not mean careless
In a blameless review you do not ask who made the mistake. You ask what made the mistake possible and easy. If one person deleted the wrong records, the useful questions are: why was the wrong action available, why was there no warning, and why was there no way back?
This is a practical choice, not a kindness. If people expect to be blamed, they tell you less, and you lose exactly the details that explain the incident. Say clearly at the start that the purpose is to improve the system and the way of working, and keep that promise in how the page is written.
The one-page format
Use the same headings every time:
- Summary: two sentences on what happened and who was affected.
- Impact: what stopped, for how long, how many people, and any data that was lost or had to be corrected.
- Timeline: times and events, in order.
- Causes: what made it possible; usually more than one.
- What helped: things that worked and should be kept.
- Actions: each with an owner and a date.
- Follow-up date: when someone checks that the actions are done.
Step one: write the timeline first
Before anyone proposes a cause, collect facts with times: when the first person noticed, who was told, what was tried, what finally worked, when work returned to normal. Take the times from messages, logs and ticket histories rather than from memory.
The timeline often shows the real problem by itself. For example, the fault may have been visible for two hours before anyone knew who should be told, or the person who understood the system was on leave and nobody had a way to reach them.
Step two: find contributing causes
Few incidents have a single cause. Ask "what else had to be true for this to happen?" a few times and write down each answer as a plain statement. Typical contributing causes in small companies are:
- a change made without a test or without telling the people affected,
- a backup that existed but had never been restored,
- one person knowing the system and no written description of it,
- no alert, so users found the fault before anyone responsible did,
- a rule that exists on paper but not in the tool.
Avoid the answer "human error" as a final cause. It ends the discussion at the point where it should start.
Step three: actions with one owner each
Turn each cause that you decide to address into one action. An action should be small enough to finish within a few weeks and be written as something that can be checked, such as "add a restore test of the order database to the monthly checklist", not "improve backups".
Give each action exactly one owner, a person and not a team, and a date. If an action is large, make its first step the action. Accept that some causes will be left alone on purpose; write that down too, with the reason. A one-page decision record is a good format for such choices.
Step four: share it briefly
Send the page to everyone who was affected, in plain words and without a long covering text. People who lost time want to know that it was understood and what will change. Store the page in a single place, for example a folder named by date and system, so that the next person with a similar problem can find it.
If the incident revealed that only one person knew how to handle the system, treat that as a finding on its own. A handover sheet is a cheap answer.
Step five: follow up
Put the follow-up date in a calendar when you write the page, usually three to six weeks later. On that day, the page owner checks each action: done, moved with a new date, or dropped with a reason. This takes ten minutes and is the part most often skipped. Without it, the review is only a record of what went wrong.
Once or twice a year, read the pages together. Repeated causes across incidents, such as untested changes or missing alerts, point to one improvement worth more than the individual fixes.
Common mistakes
- Waiting weeks, until details are forgotten.
- Writing the cause before the timeline.
- Listing ten actions with no owner, so none is done.
- Using names in a way that reads as blame.
- Holding a long meeting when a half-hour conversation and a page would do.
- Skipping reviews of small incidents, then repeating them.
Summary
A good post-incident review for an internal system is short: a factual timeline, honest contributing causes, a few actions each with one owner and a date, and a check a few weeks later. Start with the next incident that costs your team real time, write the page within three days, and keep the format the same each time.
Sources
- Our related articles linked above.
- The format and time frames are a working practice for small companies, not a formal standard; adjust them to your size, sector and any reporting duties you may have. No client results or market figures are claimed in this article.
