Someone puts up a slide that says "Knowledge-Centered Service" and suddenly everything clicks into place. The idea is elegant: instead of support agents answering the same questions over and over, you build a living knowledge base where every interaction improves the system for everyone who comes after. It's beautiful. It's also almost never what actually happens.
The promise is seductive because it works on multiple levels at once. Managers see efficiency gains. Teams see less repetitive work. Customers see faster answers. The knowledge base becomes this shared asset that keeps getting smarter. In the slide version, this is just what happens naturally once you decide it's your approach.
Then you try to actually do it.
The first thing that breaks is the assumption that people will document while they work. The slide version treats documentation like it's a natural byproduct of doing your job, the way sweat is a natural byproduct of exercise. In reality, documenting what you just figured out takes time that doesn't exist in a queue of waiting customers. An agent who takes five minutes to write up a solution is an agent who's not answering the next ticket. That math is brutal, and nobody talks about it in the meeting where KCS sounds good.
Then there's the quality problem. Not all documentation is useful documentation. Someone can write something down, technically, and it can be completely unhelpful to the next person who finds it. Maybe it's too specific to one situation. Maybe it uses internal jargon that makes sense to nobody. Maybe it's just wrong. The slide version assumes that having something written down is better than not having it written down. The reality is that bad documentation often creates more work than it saves.
The third thing is that actually keeping a knowledge base alive requires someone to care about it. That means reviewing entries for accuracy, consolidating duplicates, updating things that have become outdated, removing things that stopped working. That's a job. It's an ongoing job. In the slide version, this somehow happens. In the real version, it gets assigned to whoever has the least important other responsibility at the moment, which means it barely happens at all.
What usually ends up happening is a version of KCS that exists somewhere between the promise and reality. Maybe thirty percent of issues get documented. The documentation is uneven in quality. Some of it gets read. Some of it is outdated. The knowledge base is technically more useful than nothing, but it's less useful than the slide suggested it would be. The team is doing more work than they were before, because they're handling tickets and also trying to maintain this thing, and nobody feels like the tradeoff was worth it.
There's also something that the slides almost never address: that some teams don't actually want to work this way. They like their workflow as it is. They think documentation is tedious. They'd rather just solve the problem and move on. You can make a business case for KCS all day long, but you can't force a team to care about it in the way that actually makes it work.
The interesting thing is that KCS isn't bad as an idea. Teams that do it well have genuinely gotten better at what they do. But "doing it well" means treating it like a serious operational change that requires investment, not just like a new policy you can add to the handbook. It means accepting that some people will be better at it than others. It means building in time for documentation. It means having someone responsible for the knowledge base. It means acknowledging that this is actually work.
Most places that adopt KCS don't do any of that. They just change the slide and hope the rest follows.