Knowledge that is not wrong, just scattered
In most companies the knowledge exists. It sits in the manual, in a policy from two years ago, in the case history of a line-of-business system, and in the head of the colleague who is on holiday. People search for it every day, and the time never shows up in any report, because it is spread across many short interruptions.
You notice it in three places. New staff take longer than they should to become useful. The same question gets a different answer depending on who is asked. And one expert is the bottleneck for a whole department, because the answer is in their head rather than in a document anyone can find. A fourth sign is quieter: people paste internal documents into a public chat tool to get an answer, because that is faster than searching the file share.
Why a general chat tool is the wrong answer
A language model answers from what is inside it. The answer is fluent, plausible, and sometimes wrong, and without a source you cannot tell which. In a company that is worse than no answer, because people believe it and act on it.
A knowledge system works the other way round. Before every answer it searches your approved sources, selects the relevant passages and writes the answer from those alone. The technique is called retrieval-augmented generation. Every statement carries the passage it came from, so the reader can check it in one click. And when the system finds nothing solid, it says so. A system that invents a plausible answer when in doubt loses the department’s trust quickly and does not get it back.
How we build it
- Collect the real questions. From the support tickets, from the questions the expert gets asked, from what new starters ask in their first month.
- Take stock of the sources. Which documents answer those questions, which version is current, and who owns each one. This step usually shortens the list.
- Prepare each source on its own terms. A PDF manual with tables behaves nothing like a record from the ERP or a policy in a wiki. Each gets its own logic, plus the metadata that matters later: version, validity, owner.
- Put permissions in front of the answer. The search covers only what the person asking is allowed to read, using the permissions you already have rather than a second set.
- Build the test set. Real questions with known good answers. Every change is measured against it, and we report what it got right, what it got wrong and what it declined to answer.
- Put it where the work happens. In the line-of-business application, the ticketing system or the intranet, not in a separate tool people have to remember to open.
- Run it. New and changed documents follow automatically, old versions retire, and the questions it could not answer become the list of documents somebody should write.
A worked example: the service desk
A manufacturer’s support team answers questions about a product line whose manuals go back several generations. A technician asks for the torque setting for a bracket on a particular model year. The system answers with the figure, the manual page and the version it came from, and adds that a later service bulletin changed it, with that passage too.
The same technician asks about the terms of a specific customer’s service contract. If they are allowed to read contracts, they get the answer with the clause. If not, the system says the answer is not in the sources available to them, and it does not hint at what it could not show.
A third question, about a fault the manuals never covered, gets “not in the sources” and a route to the expert. That question goes on a list, and the list is what the expert writes up next.
What you need to bring, and when it is not worth it
You need maintained documents. If the manual is out of date, the system will cite the out-of-date manual accurately. That is usually the missing piece, and then the order of work is different: first the documents, then the system. You need an owner per source. You need permissions that exist somewhere, even if only as folder rights. And you need questions that repeat.
It is not worth it when the knowledge lives in people’s heads and not in documents. It is not worth it for a handful of documents everyone already knows. And it is not what you want when somebody needs the system to act rather than answer; that is an agent.
How it differs from the neighbouring services
A knowledge system answers and cites. An AI agent acts, and often uses a knowledge system as one of its tools. Data and analytics answers questions with figures from your systems; a knowledge system answers with passages from your documents. Enablement teaches your people to work with such tools well; it does not build one. The connection into your document stores and permissions is integration.
The next step
In the free introductory call we ask what people search for and where it is kept. Whether the questions repeat, the documents are maintained and the searching costs working time today is what the assessment checks, for a company anywhere in the German Mittelstand, before anything is built.