Two people know how it really works. Both retire soon.
A mid-sized company with technical products and many special cases. The decisive knowledge is in no system: which customer is calculated differently and why, which supplier has a history that changes the tone of a complaint, why a seemingly pointless process step exists. That knowledge lives in the heads of three or four people who have been there for decades.
Two of them retire within the next two years. What leaves with them is not facts but judgment: the look at an unusual request and the certainty that this one needs a different answer. They did try to write it down. The sentence is nearly the same everywhere: we started once, it became endless. Nobody knew where documentation should stop, so it stopped by itself.
Day to day this shows up as concentration risk. Every case that deviates from the standard runs past the same person for reassurance. Including the cases colleagues could decide themselves if they knew the reasoning. In our real projects, knowledge capture has repeatedly been the actual assignment behind a use case that was ordered as something else entirely. So we ask early: who is leaving, and when.
We start with the real cases, not with a blank page.
Every failed documentation attempt we have seen started with a template and the intention to fill it. We start at the other end, with what the company has long since produced. And the conditions of the experienced people become the specification: no forms, every entry carries their name as the release, and the questions stay short and concrete.
- Read the existing work: Mailboxes, filed cases, quotes, and documents of the area. The AI employee shows which situations recur and where the same person always decides. That is the priority list nobody had before.
- Put drafts with sources in front of them: Recurring decisions become entries made of question, source, and answer. The expert reviews a finished draft instead of facing a blank page. That reversal is what keeps participation realistic.
- Ask only about the gaps: Where the cases show the pattern but not the reasoning, the AI employee asks one question about exactly that case, by voice or chat, in a few minutes. Broad tell-me-everything sessions are explicitly not part of the method.
- Release first, then use: Nothing enters the knowledge base without the expert’s release. Once an entry is released, the AI employee uses it to answer the team’s questions, always with a visible source.
The collecting is done by the AI employee. The human decides at two points.
The AI employee runs inside your Microsoft 365 environment, the existing permissions stay untouched. It reads mailbox threads, filed cases, and documents of the chosen area and turns them into entries: the question a colleague would ask, the source cases behind it, and the answer. Where a pattern is visible but its reasoning is not, it generates a targeted interview question about exactly that case.
Judgment is not forced into rigid rules. Every entry records how solid it is: always applies, applies except under a named condition, or gut call with the reasoning. The human stays in the loop at exactly two points. They prioritize which gaps are worth asking about, and they release every entry before the team relies on it.
A customer request about a delivery date that the experienced colleague answered differently than the documentation suggests: shorter lead time promised, surcharge waived.
One field is flagged for review: the release itself. Without it, a draft never becomes an answer the team relies on.
That was before, this is today.
This is how knowledge capture ran before, and this is how it runs today with the AI employee. Instead of a documentation project that peters out after a few weeks, it costs the most experienced person about 15 minutes per week.
| Before | Today | |
|---|---|---|
| Where the knowledge sits | In the heads of two to four people | Released entries with sources, searchable for everyone |
| Effort for the expert | Blank template, endless, abandoned | Correcting drafts, about 15 minutes per week |
| Special cases | Only surface when they happen to occur | Lifted from past cases, sorted by frequency |
| Onboarding a successor | Months of learning over the shoulder | Documented base from day 1, follow-ups with sources |
| Concentration risk | Every special case runs past one person | The team decides the routine, the expert the genuinely new |
* Typical scenario, savings conservatively calculated: releases and short interviews cost the expert about 15 minutes per week, where before there were documentation projects over several weeks that got abandoned. For the handover we only count 3 months of onboarding saved, although pure learning over the shoulder often takes longer. 3 months on a position that costs the employer 55,000 to 75,000 euros per year is roughly 14,000 to 19,000 euros per succession.
How do you build an AI employee like this, technically?
The knowledge from our project work to take away, whether you build with us or on your own:
Reading: lift knowledge out of the work, not out of memory
Language models like Claude from Anthropic or GPT from OpenAI read the artifacts that already exist: mailboxes in Outlook, filed cases, quotes, documents on SharePoint. They recognize which situations recur and how decisions were actually made. This order matters: artifacts first, questions second. Only that gives the project a boundary and a priority.
Interviews: short, concrete, by voice or chat
Where the cases show the pattern but not the reasoning, exactly one question about exactly one case comes up. Not tell me how you do your job, but: why did you answer this request differently last Tuesday? An experienced person answers that in two minutes, by voice message or in chat. They never answer a blank form.
Knowledge base: every entry with its source
An entry consists of the question, the source cases, and the answer. The source is not a detail, it is the reason the team believes the answer. Anyone who wants to check where a statement comes from clicks the past case and sees the real record.
Confidence instead of a rigid rulebook
A rulebook forces a false choice: either company rule or nothing. Most valuable knowledge is neither. So every entry carries its solidity: always applies, applies except under a named condition, or gut call with the reasoning. Experienced people document far more when they are allowed to be uncertain in writing. And the successor knows when to decide alone and when to ask.
UX: the interface decides adoption
The expert gets a release queue with finished drafts they can work through in minutes. The team asks its questions and gets the answer with the source, not as a claim. And a gap board shows which knowledge still hangs on a single person. Exactly these three views turn a documentation project into a routine that lasts.

What does it cost in comparison?
Superkind charges per use case. The price grows with the scope of the knowledge secured, not with headcount. More important than the price is the timing: before a retirement you need 1 to 2 years of lead time, because knowledge capture only works while the expert is still on the job and still meeting real cases. Here is the honest comparison:
| Handover document | Wiki/intranet | Superkind AI employee | |
|---|---|---|---|
| Cost | 2 to 4 weeks of your most experienced person’s time, roughly 3,000 to 6,000 € | 5 to 12 € per user per month, plus ongoing upkeep time | Price per use case, a fraction of a full-time position |
| What is included | Whatever comes to mind while writing | Whatever someone voluntarily enters | Entries from real past cases, short interviews, answers with sources |
| Scales with | The expert’s writing time | Upkeep discipline, which is usually where it fails | The scope of the knowledge, without new positions |
| Exceptions | Drop out when they do not come to mind | Rarely make it into the wiki | Get lifted from past cases and asked about |
| Rollout | One afternoon of template, then months of delay | Weeks of structure debates | 2 to 3 weeks to the first productive version |
The honest comparison is not against zero cost but against the cost of losing the knowledge. Onboarding a successor costs months of productivity, and the concentration risk stays in place until the day that person is gone.
What we learned about preserving experience.
The most persistent pattern in our project work: knowledge capture is often the actual assignment behind a project that was ordered as something else. A team asks for an inbox assistant or a quoting helper, and two conversations later the real reason is on the table: one person knows how decisions are made here, and that person is leaving soon. The automation was the symptom, the succession was the trigger. We ask about this early now, because a project like that needs to be built differently.
The second lesson is about uncertainty. Documentation projects also fail because they only accept statements strong enough to be a rule. Most valuable experience is weaker than a rule and still far better than nothing. Experienced people happily record a judgment they would never sign off as a guideline. You just have to let them mark it in writing as a gut call with the reasoning behind it.
What it is not suited for: If your process really is written down and maintained, this brings nothing. In areas without repetition, for example one-off projects, there is no pattern to lift. And without a few committed hours of the expert’s time, do not start at all, because you would build an unreviewed knowledge base, and that is worse than none.

