Knowledge management system: why your internal wiki is empty after six months
The knowledge exists in the business, but it doesn't show up where and when the team needs it.
In this article
A new employee, third week. He asks in the group how to handle a client who requests to split a payment.
Someone answers. The answer is correct, detailed, and it took him four minutes to write it. This is the third time this year that someone has written the same answer, because each time it is written anew and buried in the group two weeks later.
In your business there is probably also a document that is supposed to contain exactly this. Someone opened it a year ago, wrote three pages, and no one has touched it since.
Knowledge, document and information: three things that get mixed up
Before choosing a tool, it is worth separating them. Information is a datum about a specific case, a document is a file, and knowledge is the way things are done.
Information is a datum about a specific case. This client, this order, this date. It lives in the operational system.
A document is a file. A contract, a form, a specification. It has a version, ownership, and who is allowed to see it.
Knowledge is how to do something. Not what happened, but what you do when it happens. It is the only one of the three that lives almost entirely in people's heads.
The confusion between the three is the reason businesses buy a document management system and expect it to solve a knowledge problem. It will not solve it. It will store files well, and all the questions that repeat in the group will keep repeating.
Why an internal wiki dies
An internal wiki dies when it is separated from the work, lacks an owner, and there is no clear reason to open it during a task.
The pattern repeats itself: it is set up, there is enthusiasm, content is moved in, and after a short while no one enters.
It is not where the work happens
This is the main reason, and it is almost never talked about.
An employee who runs into a question is in the middle of a task, inside the system where he works. If the answer is in another tool, which requires a separate search and another tab, he will ask in the group. It is faster, and from his point of view it is correct.
A position that is not convenient for enterprise content providers to voice: knowledge that is not displayed in the context where it is needed will not be read, no matter how well it is written. The procedure for handling a split payment should appear when someone splits a payment, not on a wiki page called "collection procedures".
There is no ownership
A document that everyone is allowed to edit and no one is responsible for becomes, over time, a document whose correctness cannot be known. And once it cannot be known, it is worth asking a person. And once it is worth asking a person, the document is superfluous.
Every knowledge item needs the name of an owner and a last-updated date. Two fields, and they change the attitude toward it.
There is no expiration date
A procedure written in the past describes a process that has changed since. It was not marked as wrong, because no one went over it.
Old knowledge is worse than no knowledge, because it looks authoritative. A new employee who acts according to it will make a mistake with full confidence.
What knowledge is worth documenting, and what is not
Not everything. Trying to document everything the team knows fails, because it demands time and produces a mass that no one will read.
What is worth documenting:
- What gets asked more than twice. If the same question came back three times, it is not a question, it is a missing procedure.
- What costs money or a customer if done wrong. Collection processes, handling a complaint, and what may be promised.
- What happens rarely. Precisely the rare, because no one remembers how it was done last time.
- What depends on one person. Anything only one person knows how to do is an operational risk, regardless of how talented they are.
What is not worth documenting: anything that can be turned into a field, a rule, or an automation. A procedure that says "always check that a business number was entered before issuing an invoice" is better turned into a required field. The best knowledge is the kind you do not need to remember because the system does not allow a mistake.
Documents: versions, association, and one place
A good document needs one source, a clear version, and business context. Without all three, the search becomes a guess.
Four practical rules:
- One source for every document. Not a copy in Drive and a copy in email. The moment there are two, someone will work on the old one.
- A version in place of a file name. "Final final contract 3" is a symptom, not a joke. Versions should be a property of the document and not of its name.
- A document is associated with an entity. A contract belongs to a customer, a specification belongs to a project, an approval belongs to an order. A document sitting in a folder by date will be found only by someone who remembers when it was created.
- Access determined by role and not by who knows the link. The aspect of what the customer may see and what stays internal should be defined as part of the system structure, not as a habit of employees.
| Situation in the business | The right place for the knowledge | What breaks without it |
|---|---|---|
| A question that repeats during work | Inside the process step | The employee goes back to the group |
| A contract or form | In the customer or project card | Duplicate versions are created |
| A decision about a customer | In the customer record | The reason disappears in search |
| A fixed check rule | A required field or automation | The mistake depends on memory |
| A rare process | A procedure with an owner and a date | Every time it is reinvented |
The rule that unites the four: a document reachable only through a search by file name will be lost. A document that appears in the customer card it belongs to will be found at the right time.
The knowledge that walks out the door
An employee who leaves takes three kinds of knowledge with them: what they knew how to do, what they knew about specific customers, and what they knew about why things are done the way they are done.
The third is the most valuable and is almost never documented. Why this customer gets special terms, why we stopped working with a certain supplier, and why we changed the process.
What can be done routinely, without a big documentation project:
- Decisions are recorded where they apply, not in meeting minutes. A change in customer terms is recorded in the customer card, with a reason.
- Reasons are kept from a closed list. Loss reason, cancellation reason, exception reason. After a while this becomes the real knowledge base of the business, and it is collected without anyone writing a document.
- Handover is documented along the way and not at the end. Someone who knows they will be replaced writes differently.
Where it needs to sit
There are businesses for which an organized folder and one document are enough, and that is fine. The need changes when more than one person needs to know the same thing, or when the same question repeats often enough to count as work.
In the businesses we see, the solution is not another knowledge tool but attaching the knowledge to the place where it is needed. Software development for businesses: everything you need to know before starting helps to understand why the connection between the knowledge and the operational system changes daily use.
At alcyone14 we build the knowledge and documents layer inside the same system that holds the customers, the jobs and the processes. A procedure appears at the stage where it is relevant, a document sits on the entity it belongs to, and reasons are selected from a list instead of being written as free text. We did not build a wiki, because a wiki is exactly the place no one enters in real time.
Ready to stop answering the same question?
In the businesses we see the knowledge exists, it is simply not in the place where it is needed. In a 20-minute conversation we will go over the questions that repeat most at your place, and say honestly which of them belong in documentation and which of them should not have been asked at all. If one of the questions touches on the boundaries of exposure, it is possible to start from the explanation of what the customer is allowed to see and what stays internal.
If your problem is the connection between the knowledge, the customers and the jobs, a system that holds the knowledge alongside the customers and the jobs can be a starting point for a focused conversation.
Frequently asked questions
What is the difference between a knowledge management system and a document management system?
A document management system manages files: versions, access, retrieval. A knowledge management system manages procedures and explanations, meaning how things are done and why. They meet in practice, but a business that buys the first in order to solve the second will be disappointed.
Why does nobody enter the wiki we set up?
Almost always because it sits outside the workflow. An employee in the middle of a task will choose the fastest route to an answer, and that is almost never another tab. If the knowledge does not appear in context, it competes with the WhatsApp group and loses.
How long does it take to document the knowledge in a business?
This question almost always leads to a project that fails. The approach that works is not a documentation project but a simple rule: every question that comes back for the third time becomes a documented item that same day. After a while, exactly what is needed accumulates, without any dedicated time being allocated.
How do you know that documented knowledge is still correct?
An owner and an update date on every item, and a periodic review that touches only the items that have not been updated for more than a defined period. An item without an owner and without a date is not knowledge, it is text.
What do you do with knowledge that exists only with one person?
You identify it and prioritize it by risk, not by convenience. A practical question that locates it quickly: what will happen tomorrow if a certain person does not show up for two weeks. Anything that would stop because of that is an item for documentation, and everything else can wait.
Does artificial intelligence solve this?
It helps with locating and phrasing, but it draws from what exists. A model that gets access to an outdated repository will give outdated answers with high confidence, and that is more dangerous than not getting an answer. The order does not change: first knowledge that is kept in context and updated, then a smart search layer on top of it.
Where do you start?
From the list of questions that came back this month in the team group. It already exists, it does not require research, and it is more precise than any process mapping you will do in the office.
