Your team solved it. But will they solve it again next month?

We've all been there. A tricky incident comes in. Your team investigates, digs around, eventually finds the fix. The customer is happy, the ticket gets closed. Job done.

Three months later, the same incident comes in. Different technician. Same investigation from scratch. Same fix, eventually.

The knowledge existed. It just didn't survive the ticket closure.

This is one of the most common patterns we see in service organisations, and it's easy to dismiss as a technical problem. Unstable system. Flaky integration. Vendor issue. But more often than not, it's a knowledge problem. The solution was found once, it just wasn't captured in a way that made it findable the next time.

Every repeated incident is a signal. It's your service desk telling you: something worth knowing didn't make it into the knowledge base.

The impact is bigger than it looks. Repeated incidents mean duplicated effort, longer resolution times, unnecessary escalations to senior staff, and customers waiting for answers that technically already exist somewhere. It also puts pressure on your most experienced colleagues, who end up being the informal knowledge base that everyone queries instead of a system.

The fix isn't complicated, but it does require a habit change. Treating every resolved incident not just as a closed ticket, but as a potential knowledge item. What was the issue? What caused it? What fixed it? Two minutes of documentation can save hours of repeated investigation.

This is the core idea behind Knowledge-Centered Service: capturing knowledge as a natural part of the resolution process, not as an afterthought.

Does your team have a process for turning resolved incidents into knowledge items? Or does most of that insight still disappear when the ticket closes? Would love to hear what works, and what gets in the way.