Your company's most important knowledge lives in heads and old emails. Make it findable before it leaves.
When an experienced colleague leaves, their knowledge leaves with them. Wikis capture little of it because nobody has time to maintain them. A search that looks for meaning instead of keywords makes emails, tickets and manuals usable as they are.
Fabian Weiss Key Takeaways
- Most knowledge in a company is not in the wiki. It sits in emails, tickets and heads. When a colleague leaves, it is gone.
- Search by meaning finds the old email even when the question uses different words than the answer.
- Access rights and the location of the servers decide whether such a system is acceptable in daily use. Both have to be settled at the start.
Knowledge leaves with people
Software teams have a term called the bus factor. It describes how many people would have to drop out for a project to stall. In many mid-sized companies that number is one. There is the engineer who alone understands the old machine. Or the head of sales who keeps every special price in her head.
That knowledge is not in any wiki. Experience, context and rules of thumb do not fit well into pages that are supposed to be maintained on the side. Confluence, Notion and SharePoint fill up at the start of a project and go stale afterwards. Whoever searches only finds something if they use the same word as the person who wrote it down.
The cost never shows up in any report. It spreads across replacement hiring, onboarding, repeated mistakes and customer relationships that depended on one person. Economists call it depreciation of human capital. On a company’s balance sheet it appears nowhere.
The age structure makes it worse. The baby boomer generation retires over the next few years and takes decades of process knowledge along. Recruiting alone cannot make up for it, because new people cannot bring knowledge that was never written down.
What changed since 2022
Until a few years ago company knowledge sat in folder structures. PDFs, emails, tickets. Search compared strings of characters. If you did not know the exact word, you found nothing. If you needed the answer, you asked the colleague who knew it. When the colleague left, so did the answer.
Today there is a method that sorts text by meaning. For the computer every text becomes a long series of numbers, a so-called vector. Two texts with similar meaning get similar number series, even if not a single word matches. The sentences “The server crashed” and “System outage in the data center” sit right next to each other in such a database. Search then finds answers, not just hits for a keyword.
That changes the cost picture. A search in the wiki costs the time of the person searching. If they find nothing, it also costs the time of the colleague who answers. A query to such a system costs a fraction of a cent for the language model and a few seconds. How much that adds up to for you depends on how often someone asks instead of finding today. In projects we often see that nobody knows that number, because the questions are asked in passing.
The point in one sentence
Knowledge that only lives in heads and inboxes is lost with the next departure. Search by meaning makes it usable without anyone rewriting everything.
What it looks like in daily work
A typical case: a plant engineering company with tens of thousands of maintenance manuals as PDFs, ten years of support emails and a few years of chat history from the engineers. All of it is read in once and sorted by meaning. The result is not a search box but a chat you ask questions.
A young technician stands in front of a broken machine at a customer’s site. He asks: “The pump vibrates at 50 hertz, what do I do?” The system does not search for the word vibrate. It finds an email from 2019 in which a colleague who has since retired described that for oscillations in that range a rotated seal helps. The technician has the answer in seconds. No phone call, no waiting, no colleague who is no longer there.
Two honest limits. First, even the best search only finds what existed in text form at some point. What was never in an email, a ticket or a manual stays in someone’s head. Second, the quality of the answers depends on how clean the sources are. Ten years of emails also contain ten years of mistakes. The system therefore always has to show the source, so the reader can check who wrote it and when.
What it means for onboarding
New colleagues need months before they work without help. During that time they ask a lot. Every question costs their time and the time of whoever answers. Most of those questions have been answered before, only nobody remembers where.
With such a system the new colleague asks the chat first. How do I file travel expenses? Who is the contact for project X? How do we name files? They get the answer from the whole company’s records, from day one. That does not replace onboarding by people. It does take the questions off experienced colleagues that they are answering for the tenth time. How much your onboarding time shrinks depends on your starting point, mostly on how much of your knowledge exists in text form at all.
One side effect is often more useful than expected. The questions new colleagues ask the system show you where your manuals have gaps. What is asked often and found rarely deserves to be written down.
| Question | Keyword search | Search by meaning |
|---|---|---|
| How it searches | For matching words | For similar meaning |
| What happens with different wording | No hit | Still a hit |
| Who maintains the content | People, by hand | Reading in the sources you have |
| What happens when a colleague leaves | Their knowledge is missing | What they wrote stays findable |
Access rights and data protection
The most common objection: if everything is searchable, everyone sees everything. That must not happen and it does not have to. Rights are checked while searching, not only when answering. Whoever asks a question only gets hits from documents they could open in the original. If the intern asks about the management’s salaries, the document is in the database, but their account has no read rights for HR and finance. So it is never handed to the language model in the first place.
The second point is where the data lives. Such a system can run entirely on your own servers. Ours run at Hetzner in Germany. Then index and processing stay where you want them. If you connect an external provider for the language model, that part is subject to their terms. You need to know that and decide it before the first emails are read in. Whoever treats data protection as a later step rebuilds the system afterwards or switches it off again.
Security and findability do not exclude each other. They only have to be planned together at the start.
What you can check now
- Name the three people in your company whose absence would stall the most. Write down which knowledge would go with them.
- Look at where that knowledge lives today. Emails, tickets, chat, PDFs, folders. Everything that is text can be read in. Everything else cannot.
- Clarify who may see what. If there is no overview of that, it is the first task, not the database.
- Start with one department and one source. A support inbox is enough to see whether the answers hold up.
The cost of such a query keeps falling. What does not fall is the price of knowledge that is already gone. If you want to know whether this is worth it for you, send us a short note on which sources you have and who searches them today.
Research for technical decisions
New reports, benchmarks and technical analyses on SaaS economics, AI engineering and owned infrastructure.
Original research Public sources No sales mail
By subscribing you receive new analyses and updates from FW Delta by email. You can withdraw your consent at any time. Further information is available in the privacy policy.