Ask someone who has looked after a plant for 20 years how they spot a problem. The answer is almost always: you hear it.
That is the core of the problem. 42 percent of job-related knowledge is documented nowhere (Panopto/McKinsey). Not because nobody had time to write it down, but because it does not appear as knowledge to the person who holds it. It has become routine.
Process documentation shows the ideal case. Reality consists of exceptions.
Why documentation projects do not close this gap
The classic route says: the expert writes down their tasks, someone formats it into a knowledge page, done. Three reasons the essential part goes missing.
1 The expert does not know what they know
Experience-based knowledge is automated. Someone who has made a decision 5,000 times no longer knows the criteria consciously. Asked how they do it, you get a process description, not the decision logic.
2 Nobody writes down exceptions
Documentation describes the normal case, because the normal case describes cleanly. The relevant cases are the others: what applies when supplier B fails? At what point do you escalate? Which deviation is tolerable and which is not?
3 There is no prompt to probe
A document asks no follow-up questions. Yet the follow-up question is precisely the moment where tacit knowledge becomes visible. Why a wiki fails at this structurally is set out in the piece on the Confluence alternative.
What an AI interview does differently
An AI-supported expert interview is not a chat and not a form. It is a structured conversation with probing logic, built on two established methods.
Critical Incident Technique. Instead of asking about processes, it asks about concrete incidents: tell me about the last disruption that was difficult. People recall events far more precisely than rules, and the criteria are embedded in the telling.
Decision-Point Decomposition. Every described action is broken down into its decision points. How did you recognise that? What alternative did you have? Why this one? What would have happened if you had decided wrongly? At what point would you have escalated?
The result is not a transcript but a structure: criteria, exceptions, warning signals, heuristics, dependencies, escalation paths.
The process in four phases
Knowledge capture rarely fails at the interview. It fails at what does not happen before and after. So the interview sits inside a four-phase sequence.
IDENTIFY. Which knowledge is critical and at risk? Not all knowledge is equally important. Prioritisation follows risk: key roles, planned departures, processes with high damage potential, single-person dependencies. Which criteria work for that is set out in the piece on the retirement wave.
CAPTURE. The interviews. An experience value from practice, among others at Hörmann and BASF: expect roughly four weeks per expert for a solid capture, spread across several sessions. That is a typical value, not a commitment.
CONSOLIDATE. The step most people underestimate. Statements from several people contradict each other. Review runs along five quality dimensions: correctness, currency, relevance, freedom from conflict, completeness. Contradictions are not averaged, they are resolved.
ENABLE. Availability in everyday work. As knowledge articles, playbooks, SOPs, training videos, an internal podcast, and as context for chatbots and AI agents via RAG API, REST API and MCP server. Why exactly this step decides the answer quality of internal AI is set out in the piece on RAG architecture for enterprise.
What comes out at the end
Not an archive. A playbook that guides a decision.
An example of the output form: a shift supervisor faces disruption X. Which checks in which order? How do they recognise it is the rare case? When do they escalate, to whom, with what information? Which exception applies to plant 3 because its piping differs?
Every knowledge object carries an owner, a validity date and a verification status. That is the difference between a wiki entry and a reliable basis.
The questions that always come
What does employee representation say?
That is the decisive question, and it belongs early rather than late. Three points carry the discussion: voluntary participation, transparency about purpose and use, role-based access control with an audit trail. The framing matters: this is about role knowledge, not performance assessment of individuals.
Does this not make experts feel replaceable?
The concern is real and cannot be argued away. In practice a different framing works better: whoever secures their knowledge is freed from routine queries and is needed for the cases that genuinely require experience. Typically queries to experts drop by 20 to 40 percent.
How long until something is usable?
For a first usable slice of a role, under 14 days is possible. For a solid capture of a key role, expect closer to four weeks. Both are experience values.
Does this work when the person has already left?
No. That is the hard limit. Experience-based knowledge can only be captured while the person is available. After that the expensive route remains: departed experts return as consultants at two to three times the daily rate, according to HBR.
Where to start
Not with a programme. With one role.
Pick a person whose departure is due in the next 24 months and whose knowledge is operationally critical. Capture that one role completely, make the result available to the team, and measure a single number: how many queries still reach that person after four weeks?
That number is your business case. It comes from your company, which makes it more solid than any benchmark.
