Every closed incident is a lesson you keep or lose
· 1 min read
Capture what you learned at incident closure, while the detail is still fresh, with a named owner.
In brief
Closing an incident is not the same as learning from it. The ticket is closed, everyone moves on, and the one person who worked out what went wrong carries the answer home in their head. Next month the same symptoms appear and someone else starts from nothing. That is not bad luck. It is knowledge the organisation paid for once and chose not to keep.
This article argues that the moment to capture the lesson is the moment of closure, while the detail is still fresh, not at a quarterly review. Three questions are enough: what did people see, what was actually wrong, and what fixed it. A rough note written today beats a perfect article that never gets written. Give the lesson a named owner who checks it, sharpens it and decides whether it belongs in the knowledge base. The test is simple: when this happens again, will the next person find the answer in minutes, or rediscover it in hours? Join the conversation on ESM's Exchange.
Keep the lesson or lose it
Every closed incident is a lesson. You either keep it or you lose it.
The incident is fixed. The ticket is closed. Everyone moves on. And the one person who worked out what went wrong carries the answer home in their head.
Next month it happens again. Someone else starts from nothing. Same symptoms. Same searching. Same late finish.
That is not bad luck. It is knowledge you paid for once and chose not to keep.
Capture it at closure
The moment to capture it is the moment of closure. Not at the quarterly review. Not when someone finds the time. While the detail is still fresh.
Keep it small. Three questions are enough:
- What did people see?
- What was actually wrong?
- What fixed it?
A rough note written today beats a perfect article that never gets written. It can be tidied, reviewed and improved later. It cannot be remembered later.
Give the lesson an owner
Someone checks it, sharpens it and decides whether it belongs in the knowledge base. Accountability needs a name.
The test
When this happens again, will the next person find the answer in minutes, or rediscover it in hours?
Next step
How many of last month's incidents left something behind? Join the conversation on ESM's Exchange: https://exchange.esm.institute
Tags: knowledge management, incident management, service management, ESM
Join the Exchange free
Join free to unlock the complete knowledge library.
Founder membership is free for life
More from Esm
How should the service desk handle a Microsoft 365 outage it cannot fix?
4 min read
Deploying AI is the easy part: who runs it once it goes live?
5 min read
How do I compare help desk tool pricing before rolling it out across several departments?
4 min read
Turning 'not helpful' into a fix
1 min read
When the author leaves, who owns the article?
2 min read
Test after every change, or find out from users
1 min read
Related articles
How should the service desk handle a Microsoft 365 outage it cannot fix?
Treat a supplier cloud outage as your own major incident: log it once, tell people early on a channel that still works, update on a rhythm and review your dependency afterwards.
Deploying AI is the easy part: who runs it once it goes live?
Only a third of large enterprises have met the business case for their main AI programme. New research points to a gap in who runs AI after launch, and what leaders can do.
How do I compare help desk tool pricing before rolling it out across several departments?
Compare help desk tools on a full year's cost for your real agents, approvers and requesters in every department, not on the headline monthly price.
Turning 'not helpful' into a fix
'Not helpful' is free, honest feedback, and most of it goes nowhere. Turn that click into a fix.
When the author leaves, who owns the article?
Articles keep being read after their authors move on. Make sure the care for them does not leave too.
Test after every change, or find out from users
Knowledge changes fail quietly. A short, repeatable test after every change finds the problem before your users do.