Is Your Company's Knowledge Base a Ghost Town? Check These 3 Mechanisms First

After a knowledge base has been live for a while, updates stop. Employees still use it, but search results are contradictory; questions go unanswered, and no one updates the documentation. Business owners often blame employee laziness or choosing the wrong tool. My take: neither is usually the case.

Most knowledge base failures aren’t due to software or a lack of willingness, but rather the absence of three critical governance mechanisms: write incentives, clear ownership, and expiration cleanup. Until these three issues are addressed, switching tools won’t help, and adding AI will only make things worse. Let’s break them down.

Diagnose Mechanisms First, Then Talk Tools and RAG

When a company considers an AI-powered knowledge base, the most common impulse is to buy a system with RAG (Retrieval Augmented Generation). RAG, simply put, allows AI to consult internal documents before answering questions, rather than fabricating information. This sounds like the perfect solution to revitalize a knowledge base.

The problem is: RAG can exacerbate existing issues. If your knowledge base is full of outdated, conflicting, or unowned documents, the AI will simply retrieve this garbage and present incorrect answers in a very confident tone. Users will instinctively trust it because it sounds so certain. This is far more dangerous than “finding an old document through search”—stale content can mislead AI models trained on historical data, reinforcing practices that have long been abandoned.

This is the same root cause behind why AI pilots often succeed but fail at scale: technology outpaces governance. As I discussed in Why AI Pilots Succeed But Fail at Scale: It’s Not the Model, mechanism problems don’t disappear just because you introduce a smarter model, and this is especially true for knowledge bases.

I reached a similar conclusion in my notes on Glean: what’s genuinely hard, and genuinely valuable, in enterprise AI is the grunt work of permissions and context—who is allowed to see what—not the model itself. Whether content has an owner belongs to that same layer.

Therefore, the sequence should be: first diagnose the three mechanisms, then decide which tools to buy or whether to implement RAG.

Mechanism One: Write Incentives – People Who Don’t Write Aren’t Usually Lazy

In small and medium-sized businesses (SMBs), the people with the most business knowledge are often the busiest. A seasoned quality control technician might know a hundred ways to identify product defects, but if you ask them to write documentation, they’ll say, “It’s all in my head, just ask me.” They’re not wrong, but it’s not the complete picture.

The core conflict is: writing and updating documentation is rarely factored into performance reviews. Employees are evaluated on their operational output, while knowledge base contributions are “extra work” that doesn’t impact their income, so it always gets pushed aside by other priorities. This isn’t about lazy employees; it’s about the organization failing to give this task its proper place.

The consequences accumulate. Employees spend a significant amount of time each year searching for information, and a substantial portion of that time is wasted because they can’t find what they need—one survey found that remote employees spend an average of 2.5 hours per day searching for information, with 40% of that time lost due to an inability to find required knowledge. While this data isn’t specific to SMBs, the trend is clear: excessive search time indicates that the knowledge base isn’t capturing what needs to be captured.

A more insidious loss only becomes apparent after someone leaves. A LinkedIn report indicates that 60% of companies believe knowledge loss from core employee departures is the primary factor affecting team continuity. In small and medium manufacturing businesses, the knowledge a seasoned technician takes with them when they leave often far exceeds the value of a piece of equipment.

Incentives don’t need to be complex. A lightweight approach is to include “which documents were written or which SOPs were updated” in project closeout checklists, to be reviewed alongside other deliverables. A more direct method is to incorporate knowledge contributions into performance reviews, even if it’s a small percentage. Some tech companies have implemented this, seeing a 300% increase in employee knowledge contributions. You don’t need to adopt a large corporation’s entire system, but the basic action of “document it, record it, reward it” is essential.

Mechanism Two: Clear Ownership – Every Document Needs a Person, Not a Department

The second common ailment of knowledge bases: a document is viewed by ten people, but zero people are responsible for it. Suppose a sales department’s quote template is outdated. Customer service discovers the error but doesn’t know who to contact to fix it, so they resort to verbal communication. Three months later, the error is likely still in the document.

Without clear ownership, neglected content remains visible indefinitely. This isn’t a technical flaw; it’s a lack of accountability. If a document only states “maintained by the Marketing Department,” it effectively means no one maintains it—because “the Marketing Department” won’t receive reminders, won’t conduct annual reviews, and won’t feel pressure during performance discussions.

The solution is concrete: every document intended for long-term survival must have a specific person’s name listed under its title. Not a department, but a specific individual. This person’s responsibility isn’t to update it daily, but to: respond when errors are pointed out, periodically confirm the content is still valid, and transfer ownership before leaving the company.

Tools like Confluence Cloud already support assigning owners to content and filtering pages that haven’t been touched for a long time. This isn’t difficult. The challenge lies in management accepting a fundamental truth: without an owner, no one will take responsibility.

SMBs can simplify this: not every document needs an owner, but any document affecting production, quoting, compliance, or customer service processes must have a named owner. For other low-value content, whether an owner is assigned is less important, as it should ideally be archived.

Mechanism Three: Expiration Cleanup – Old Knowledge is Worse Than No Knowledge

Even with people writing and managing content, it will eventually become outdated. If old versions persist in the system, they will coexist with correct versions, leaving employees unsure which to trust. Conflicting versions of policies, guidelines, or process documents leave employees confused, ultimately leading them to bypass the system altogether and revert to informal chats or verbal confirmations.

A typical consequence occurs in customer service: ahead of a major sales event, one e-commerce company discovered its customer service team was still working from a product spec manual three months out of date, and customer complaints surged by 40%. The same applies to an export business: if their customer service quotes old shipping costs, tariffs, or delivery times, they lose inquiries one by one, and customers won’t tell them why.

The mechanism is clear: every document must have a “next review date” set at creation. If not reviewed by that date, it should be automatically deprioritized or archived. Many tools can implement automated rules. Confluence Cloud’s automation can be set to notify the owner and then archive a page if it hasn’t been viewed or updated for a certain period. This logic can be applied to Feishu (Lark), Notion, or any system with basic automation capabilities.

For SMBs, pursuing a complete cleanup of all content is not recommended; it can become an endless new project. A more realistic strategy is to enforce timely reviews only for critical documents, and automatically archive all other content that hasn’t been updated for over two years. Archiving doesn’t mean deleting—“can’t find it” and “it’s gone forever” are different. Archived content is not discoverable by users but can be restored if needed, avoiding conflicts without permanently erasing historical records.

A Practical Checklist You Can Use Today

As a digitalization or IT lead, you need to provide your boss with a knowledge base “health check” report. Ask the following three sets of questions. The answer is simply “yes” or “no”; anything you can’t answer counts as “no.”

Write Incentives

• Are employee contributions to writing or updating documents factored into any form of performance review or reward?
• Does your project closeout checklist include an item for “which documents were created or updated”?
• Do frontline employees, who possess the most business knowledge, have dedicated time allocated for writing documentation?

Clear Ownership

• Do critical process documents have the name of a specific responsible person listed under their title?
• When this person leaves, is there a knowledge transfer process, not just a job handover?
• If an employee finds an error in a document, do they know exactly who to notify?

Expiration Cleanup

• Do critical documents have a “next review date” set at the time of creation?
• Is there an automated rule in your system that archives documents that haven’t been updated for a long time?
• In the past three months, have any outdated or conflicting documents been cleaned up?

If most answers across the three groups are “no,” the conclusion is clear: the problem isn’t the tool. Hold off on buying new systems and focus on fixing the underlying mechanisms first.

When This Assessment Might Not Apply

These three mechanisms are not a panacea. In some scenarios, the knowledge base itself isn’t the core issue.

First, for very small teams, say ten people or fewer. At this scale, the friction of writing formal documents can be too high, and verbal communication is often faster. Instead of building a knowledge base, it’s better to simply write down core processes on a page or two and agree to communicate key changes in person.

Second, when knowledge is highly tacit and difficult to document. For example, the experience of certain master craftsmen in precision machining, where judgments like “this sound isn’t right” can’t be captured in text. Such knowledge requires on-site shadowing, video recording, or even equipment data annotation, and knowledge base software won’t be of much help. In these cases, establishing mentorship programs is far more important than buying tools.

Third, when business changes too rapidly, and documents become obsolete as soon as they’re written. For instance, a dropshipping e-commerce business with products changing every two weeks—writing detailed SOPs is pointless. Such organizations don’t need a knowledge base; they need highly flexible shared chat logs and instant correction processes.

Finally, if the knowledge base is already completely dead. Not just unupdated, but everyone defaults to assuming it’s wrong. In such cases, adding more rules won’t revive it. A more practical approach is to start fresh, putting only truly effective current documents into a new system, complete with owners and review cycles.

---

References

• Data Retention in Confluence Cloud: Avoiding Stale Knowledge and Enhancing Retention Management
• 2025 Knowledge Management Trends: How Enterprise AI Knowledge Bases Reshape Knowledge Management Systems