Knowledge management when nobody writes the articles

The maintenance trap

You've seen this cycle. Someone on leadership decides the team needs a better knowledge base. There's a kickoff meeting. Everyone gets assigned articles to write. For two or three weeks, articles pour in. The KB goes from sparse to populated. It feels like progress.

Six months later, the UI has changed and the screenshots are wrong. A workflow was updated but the article still describes the old process. The person who wrote the most detailed article in the KB moved to another team. Nobody noticed the article was wrong until an agent followed it step by step and made things worse for a customer.

The problem isn't the initial writing. It's the maintenance. Every article is a commitment to keep it accurate forever. A KB with 200 articles needs 200 articles reviewed and updated every time the product changes. Nobody budgets for that, nobody owns it, and the articles drift quietly until they're worse than having no article at all. Wrong documentation is more dangerous than missing documentation, because agents trust it.

Why "write more articles" doesn't work

Writing competes with answering tickets. Your agents have a queue. Every minute spent writing an article is a minute not spent resolving a customer's problem. The agents who know the most are the busiest, because they handle the hardest tickets and other agents come to them for help. The agents with time to write are the newest and know the least.

Most KB initiatives produce a burst of content in month one, a trickle in month two, and silence by month three. The incentive structure makes this inevitable. Article writing is uncompensated extra work on top of an already demanding job. Agents get measured on tickets resolved, not articles written. Even when managers add "KB contributions" to performance goals, the reality is that a ticket waiting in the queue always feels more urgent than a KB article that might help someone someday.

This isn't a discipline problem. It's a structural one. The people who have the knowledge don't have the time. The people who have the time don't have the knowledge. Asking agents to write more articles is asking them to do a second job on top of the one they were hired for.

What your team already does instead

Your team has a knowledge management system. It's just not the one you planned.

It's resolved tickets with detailed internal notes. It's saved replies that encode solutions into reusable templates. It's Slack threads where someone asks "has anyone seen this before?" and gets a useful answer in minutes. It's screen recordings agents send each other to demonstrate workarounds. It's the senior agent two desks over who remembers the fix because they handled the same ticket eight months ago.

This informal system works surprisingly well for most issues. The knowledge is current because it was created during actual ticket resolution, not during a dedicated writing session weeks later. It's practical because it comes with the context of a real customer interaction. It's trusted because agents know it worked at least once.

The problem with the informal system isn't that it's informal. It's that it's fragile. Slack threads scroll past and become unsearchable. The senior agent goes on vacation. Someone leaves the company and takes their knowledge with them. The information exists, but it's locked inside conversations and people's heads instead of being durably accessible.

The 80/20 of knowledge bases

Your top 20 or so KB articles probably handle 80% of self-service deflection. These are the password reset guides, the getting-started walkthroughs, the common error explanations. They're viewed hundreds or thousands of times a month. Each view that resolves a customer's question is a ticket that never gets created.

Focus your quality effort there. Keep those 20 articles current, tested, and accurate. Assign an owner to each one. Review them after every product release. Test them by following the steps yourself. These articles earn their maintenance cost many times over in deflected tickets.

For the long tail of hundreds of less-common issues, searchable past tickets are more practical than trying to write and maintain a dedicated article for every possible problem. A resolved ticket with a clear internal note is a perfectly good knowledge artifact. It doesn't need to be reformatted as a polished article to be useful to the next agent who encounters the same issue.

This is the shift that makes knowledge management sustainable: stop trying to turn every piece of knowledge into a formal article, and start making your existing knowledge artifacts findable. Your resolved tickets are a knowledge base if you can search them effectively.

Making the informal system work

The informal knowledge system fails in two scenarios: when people leave, and when conversations scroll past. Fix those two failure modes and you have a knowledge system that maintains itself as a byproduct of normal work.

Encourage detailed internal notes on every ticket resolution. Not "fixed it" or "resolved." What was the actual problem? What was the fix? Were there any gotchas? This takes 30 seconds more per ticket and turns every resolution into a reusable artifact. Agents resist this at first because it feels like extra work. But the first time a new hire finds a past resolution through an internal note and solves a ticket in 5 minutes instead of 45, the value becomes obvious.

Invest in finding past resolutions, not writing new documentation. Your team has already solved thousands of issues. The bottleneck is retrieval, not creation. An agent searching for "customer can't see their invoices" needs to find the ticket where someone wrote "billing portal access issue after plan upgrade." Those are the same problem described in different words, and keyword search won't connect them.

Change how your team thinks about closed tickets. A resolved ticket is not a dead record to archive. It is an answer that someone on your team will need again. The knowledge your team creates while resolving tickets is the most current, most practical, most battle-tested knowledge you have. Build a workflow where agents write internal notes for the next person, not just for the audit trail. Every resolution becomes a contribution to the team's collective memory.

Frequently asked questions

Should we stop maintaining our knowledge base?

No. But stop trying to make it comprehensive. Focus quality on the 20 or so articles that handle 80% of self-service deflection. Keep those current, tested, and accurate. For everything else, invest in making your resolved tickets searchable rather than trying to write and maintain an article for every possible issue.

How do we handle knowledge from agents who leave?

By the time someone gives notice, it's too late to do a knowledge transfer. The real fix is making knowledge durable as it's created. Encourage detailed internal notes on every ticket resolution. Make resolved tickets searchable. If an agent's knowledge only exists in their head, it was never really part of your knowledge system. The goal is to make every resolution a reusable artifact so that departures hurt less.

What about customer-facing KB articles?

Customer-facing articles are a different problem with different economics. They deflect tickets, which saves money. The ROI on keeping your top 20 customer-facing articles accurate is clear. But the maintenance burden is the same: articles decay and nobody updates them. Apply the 80/20 rule here too. Maintain the high-traffic articles aggressively and let the long tail be covered by your support team.

How do we measure if our knowledge management is working?

Track knowledge reuse rate: how often agents reference past resolutions, KB articles, or saved replies when resolving tickets. Track time-to-resolution for known issues versus novel issues. If the gap is large, agents aren't finding existing knowledge. Track duplicate ticket rate over time. If it's dropping, your knowledge system is working. If it's flat, the knowledge exists but agents can't access it.