A business owner told me he spent 28,000 yuan last year on a knowledge base.
Go-live day was a proper occasion — a meeting, photos, two rounds of all-staff training.
Three months later I asked him whether anyone was still using it.
He paused, then said: “I think… nobody brings it up anymore.”
I asked him to pull up the access log. Over seven days, the number of people who had opened it on their own initiative was 3.
Two of them were IT. The third was him.
What he paid for was not a broken system.
The problem was not the goods.
What he bought was something that nobody had looked after since the day it was accepted.
First, my own conclusion: acceptance as the finish line
In the years I have spent putting enterprise knowledge bases into service, I have seen every kind of failure.
Version too old, documents too messy, model not good enough, staff don't know how to use it — the list of reasons is endless.
But strip away the surface reasons and the same structure sits underneath:
Almost every company — very likely including yours — treats “acceptance” as the finish line.
Contract signed, system live, demo passed, signature and payment — once the process is complete, the matter is considered closed inside the company.
So the resources are withdrawn, the people are withdrawn, the attention is withdrawn.
But with a knowledge base, the value only starts growing from the moment it is accepted.
Before acceptance, it is a pile of documents.
After acceptance, it begins to become “someone asks, someone answers, and when the answer is wrong someone fixes it”.
One is a finish line, the other is a starting line. When the two are misaligned, the rest is only a matter of time.
The industry data backs this up.
Public industry statistics for 2026 put it at 90% of company-built knowledge bases ending up as “zombie document libraries” — either nobody uses or updates them, or the AI Q&A is pure decoration.
A harsher case: a credit card centre at a state-owned bank invested 3 million yuan in a smart knowledge base, and that went idle as well.
Money is not a moat. 3 million yuan and 28,000 yuan produced exactly the same outcome.
Why three months is the breaking point
Not mysticism — three layers stacking on top of each other.
Layer one: if the first search fails, they never open it again.
Your staff give a knowledge base exactly one chance.
The first time your team asks “the customer wants a return but it is past seven days, what do we do”, the system returns a pile of irrelevant text; the second time they do not ask — they go and ask the colleague next to them. The one who always knows the answer.
This is not your staff being impatient. It is trust being a one-time purchase.
That first experience decides what it is in your employee's mind: “a tool I can actually use”, or “another form I have to fill in”.
Layer two: knowledge expires, but nobody owns keeping it fresh.
Your business changes, the policy changes, product specs are adjusted — and the documents sit exactly where they were.
One 2026 selection guide had a line that stuck with me: a knowledge base with no update mechanism becomes an “information dump” after three months.
Three months. That is not my invention; it is a timescale repeatedly verified across the industry.
Layer three: a one-off procurement process up against something that needs long-term feeding.
This layer is the most damaging for you, because it grows inside your processes, not inside the technology.
Your procurement process ends at the words “accepted as compliant”.
But a knowledge base is industry-recognised as an operational system, not a one-off engineering project — its components include continuous document updates, removing stale material, optimising Q&A feedback, and unifying terminology. Four things, none of which can appear on an acceptance form.
A 2026 selection review put it bluntly: “Many companies leave them unmaintained after go-live, so the knowledge base fills with outdated information and eventually becomes a zombie system.”
So a zombie library is not a technical failure.
It is an institutional failure.
Three independent data points, one conclusion
My habit: for any conclusion, find at least two independent sources and cross-check them.
The first: IBM's 2026 survey on why AI agents fail.
(An “agent” here means an AI that can actually go and do work, not just chat with you.)
| Rank | Cause of failure | Share |
|---|---|---|
| 1 | No evaluation framework — no way to measure whether the AI is doing a good job | 64% |
| 2 | Governance friction — IT, legal and compliance approvals grind to a halt | 57% |
| 3 | Insufficient model reliability — hallucination, inconsistent behaviour | 51% |
Note this: not one of the three is “the model isn't strong enough”.
Number one is “no way to measure whether it works well”.
In plain terms: nobody defined what success meant when you bought it, so in use you can only go by feel, and when it feels bad you stop — not because it broke, but because nobody can say whether it is good.
The same survey has another number: IBM's CEO survey showed that only 25% of AI projects delivered the expected ROI.
One in four. The other three mostly died somewhere you did not notice.
The second: what makes agent projects fail.
A 2026 technical community retrospective gave a number: when enterprise agent projects fail, 70% of the time the cause is not the wrong model but a badly built knowledge base — documents scattered everywhere, formats all over the place, no update mechanism.
The third: what the control group looks like.
Investors' media reported a positive case: a company used to spend 60% of its time helping sales solve problems, and 80% of those problems were recurring and had standard solutions.
After bringing in an AI assistant, the share of problems solved self-service rose to 30%.
Notice the difference — it first worked out the “repetition rate” and the “degree of standardisation” before deciding to adopt AI.
This is not a technology gap. It is a sequencing gap.
Three things you can do today
No opinions, only things you can act on.
One: work out whether yours is a live library or a zombie library (5 questions, each answered yes or no)
1. In the past 7 days, has anyone outside IT opened it on their own initiative?
2. In the past 30 days, have more than 10 knowledge entries been added or edited?
3. Is there a named person responsible for “this answer is wrong, who fixes it”? (A name, not “everyone”)
4. Can you quantify whether it is any good right now? (Accuracy, correct-answer rate, hand-off-to-human rate — any one of them)
5. On your acceptance form, is there a single line about post-launch operating metrics?
4 or more “no” = your library is already on the road to becoming a zombie. Not possibly. It is happening.
Two: change the acceptance standard from a feature checklist to operating metrics.
Next time you procure or sign off, add this line:
Within 90 days of go-live: Top-5 accuracy no lower than 80%, hallucination rate no higher than 10%, hand-off-to-human rate down quarter on quarter.
Both numbers are openly used industry benchmarks — best-in-class hallucination rates sit below 5% (after multiple layers of optimisation), and the acceptable threshold is usually set at Top-5 ≥80% with hallucination ≤10%.
With that line, acceptance becomes a starting line; without it, acceptance is guaranteed to be the finish line.
Three: calculate one number — what share of your problems are repeats.
Take the last 50 real customer enquiries or internal questions and count:
- How many had been asked before?
- Of those, how many have a standard answer?
In that control group the two numbers were 80% and “most of them”. If your repetition rate is below 30%, do not rush into AI — not that you cannot, but the return does not justify it.
FAQ
Q: Our documents are already a mess — do we have to tidy everything up before we put a system in?
A: You do not have to finish tidying, but you do have to decide who is responsible for tidying. Tidying with no owner will end up messy again. With an owner, tidying as you go live is actually faster — because usage feedback tells you which documents are worth fixing first.
Q: We are a small company with few people — are we structurally unable to run a knowledge base?
A: Fewer people is an advantage. Under 30 staff, one responsible person is enough, the feedback loop is short, and a knowledge fix can take effect the same day. Large companies stall at exactly this step, because “who fixes it” has to clear three approval layers.
Q: We already paid for a system — do we have to buy a new one?
A: In the overwhelming majority of cases, no. A zombie library is usually “stale content plus nobody responsible”, not “the system is bad”. Set the owner, clear out the expired entries once, and list the questions answered wrongly in the last 30 days — after those three things, most libraries come back to life.
Q: How do I persuade the boss to spend more money on “operations”?
A: Do not talk about operations; talk about the cost of paralysis. Put that 64% failure figure from AI projects on the table — “no way to measure whether it works well” is the number one killer. Then ask him one question: can we currently say whether it is working well or not? If he cannot answer, that is your most persuasive argument.
Q: What if I am that “one person who always knows the answer”?
A: You may well be the single most valuable asset in the company. If you took three days off, how many things would jam? Work out that number first, and you will know whether it belongs outside your head.
What we actually deliver
The three things above, you can do yourself. What we take on is the part you cannot get to:
- Before it goes in: turning documents scattered in different places, and spreadsheets in wildly different formats, into structured material that can be searched and asked. The industry calls this “knowledge governance” — in plain terms, making it findable by a machine.
- After go-live: regular health checks — collecting the questions answered wrongly, clearing expired entries, unifying terminology.
- What we commit to: only that the process is verifiable (every enquiry and every correction leaves a trace), never that you will be cited or recommended — and that clause is written into our contract.
Who we are — SavantCat (合尘猫), delivering enterprise knowledge bases and AI customer service for small and micro businesses with fewer than 200 employees. A one-person team plus AI, working on “the part after go-live”.
If you also have a library that is going quiet, start with just the first thing: those 5 questions, answered one by one. Once you have, you will know whether it is urgent.
#enterprise knowledge base #AI customer service #SME digitalization #knowledge management #AI adoption
Sources
1. CSDN, 2026 statistics on company-built knowledge bases (cited in the Zhihu Q&A “How to build an enterprise knowledge base”)
2. Tencent Cloud Developer Community, “Knowledge-Organisation Transformation Path: Building AI Knowledge Management from 0 to 1 in 3 Months” (includes Gartner's 2026 view)
3. IBM, 2026 survey on why enterprise AI agents fail (cited in the Zhihu article “The Real Progress of AI Agents in the Enterprise”)
4. segmentfault, “The First Barrier to Enterprise Agents: It Is Not a Weak Model, It Is a Badly Built Knowledge Base”
5. PEdaily (投资界), “In the Agent Wave, Where Has the Knowledge Base Landed?”
6. “2026 Enterprise AI Knowledge Base Selection Guide: Architecture Comparison, RAG (Retrieval-Augmented Generation) Capability Assessment and Implementation Path”
7. “How to Choose an Enterprise AI Knowledge Base System in 2026: A Deep Review and Pitfall Guide”