Knowledge interviews alone are not enough: what we learned building hAiner

A knowledge interview is a conversation in which someone with a lot of experience explains what they know and is asked targeted follow-up questions. In hAiner, an AI conducts this conversation, in short sessions and ideally by voice. Every statement is stored with the person and the date.

The advantage of the method: nobody has to write a manual. Most people find talking easier than documenting. Why company wikis fail at exactly this hurdle is covered in Why company wikis fail.

A second idea was also there from the start: knowledge should not sit as a loose collection of text but be attached to the things it is about, that is, to employees, machines, products and processes. This framework has proved itself. Where we misjudged was how it gets filled.

Working with our customers, it quickly became clear that knowledge cannot be neatly divided into heads and documents. Much of it is in documents, much of it in a company's processes. And employees' experiential knowledge almost always relates to exactly these things.

Some companies work in a very structured way along their documents and processes, and there knowledge can be passed on along that structure. More often, it is the small things that sit unsorted in people's heads: that a machine starts up differently after the weekend, that a customer wants their goods packed differently, or which colleague can help with a particular complaint. Such tips are not peripheral knowledge. Often they are precisely the ones that carry the most weight.

An interview brings them out. But without the machine, the customer or the process they belong to, hardly anyone will find them again later. That is why hAiner now works with a company's existing documents and systems from day one. The knowledge in people's heads thus gets a place to attach to. Why experiential knowledge is so hard to secure is covered on our topic page Securing experiential knowledge.

A scheduled interview captures what occurs to a person during that session. But much of it does not occur to them there; it comes days later: at the machine, after a customer call, at handover to the next shift. By the next interview, it is often gone again.

From this we learned that hAiner has to run alongside day-to-day work instead of only asking at fixed appointments. Anyone who knows something should be able to get it out by the shortest route: by voice, on their phone, in a few sentences. hAiner then recognizes what the statement refers to, such as a process, a product, a machine, a device, a project or a colleague, and attaches it there. If the reference is ambiguous, it asks. Anyone who wants to can also use this as a kind of logbook and record thoughts about their working day. Such entries can be kept private or shared with specific colleagues.

The interviews still exist, especially where someone is leaving in the foreseeable future. But they are one of several ways knowledge gets into hAiner. Our image for this: hAiner should be ear, brain and voice in the company at the same time. It listens, it links, and it speaks up when something does not add up.

Running alongside does not mean that everything ends up with everyone. The company itself decides where knowledge flows: departmental knowledge can stay within the department, other knowledge is deliberately shared with everyone.

As soon as documents, the website and employees' statements sit side by side, contradictions become visible. In a test run using only the public website of a mid-sized company, the data sheets for five products belonged to other products. A single question to hAiner was enough to discover this. We described the case in Wrong data sheets on the website.

What we learned above all: an error that has been found is worth little if it lands in a general inbox or on a list nobody works through. The decisive question is who can fix it.

In every company, each person has their tasks, and their knowledge is usually tied to exactly those tasks. The person responsible for a data sheet has rarely noticed the error themselves. For hAiner to pass a contradiction to the right place, it has to know who is responsible for what. And it has to be able to judge what is urgent and what can wait. So that a note does not get stuck again, tasks can be assigned to colleagues and tracked in hAiner.

That is why linking people, tasks and things correctly has become so important to us. The same logic applies when hAiner cannot answer a question: it says so and names the person who might know.

With or without hAiner: there are three things we now recommend to every company that wants to secure experiential knowledge through interviews.

1. Clarify before the interview what the knowledge relates to. Which machines, products, customers and processes are involved? File statements where someone will look for them later, not in a folder called “Interviews”.
2. Create a short route for what comes to mind in between. A voice note straight after a job is worth more than an appointment in three weeks.
3. Decide who receives corrections. Anyone who starts collecting knowledge will also find errors in existing documents. Without clear responsibility, they stay where they are.

One limit belongs here too: hAiner only knows what someone has said or filed. It does not replace the conversation with the colleague who is about to retire. That conversation simply has more impact when it does not stand alone.

How hAiner works in detail is described in Who or what is hAiner?. If you would like to see what this could look like in your business, book an introductory call with live demo (45 minutes, free of charge).