Ask a business owner to write down how they work and you get a four-page document. Ask them right after how they built that quote from last week, and you get twenty minutes of reasoning that appears nowhere in those four pages.

That gap is the subject of this piece. Capturing knowledge rarely fails because people don't want to. It fails because the format we try it in is the wrong format.

01 / the patternWhy does knowledge leak away?

Because it never settles anywhere. Every working day you make dozens of small decisions that never land anywhere. Why this client gets an exception and that one doesn't. Which question you ask when an intake goes too smoothly. When it's better to turn down a job.

Those decisions are your craft. They're also exactly the part your systems don't see. A CRM records that a quote went out, not why it was built that way. A timesheet knows a job took twelve hours, not that eight of those went to one exception you could have seen coming.

Your systems record what's finished. Your knowledge sits in what came before it.

The result is a business that runs on paper and in practice hangs on you. Everyone can execute the steps. No one can make the judgment calls. So everything that deviates comes back to you, and in knowledge work deviation isn't the exception, it's the bulk of the work.

02 / the typesWhat knowledge should you actually capture?

Not everything. That's the first turn where most attempts crash: people start at the beginning and write a handbook. It takes months and nobody reads it, because it's full of things everyone already knows.

Knowledge in a business splits into three types, and each needs a different treatment.

Whoever wants to capture knowledge and starts at row 1 does the work with the least payoff. The pain sits in rows 2 and 3, and those two don't come out of a template. They come out when someone keeps asking questions.

03 / why it failsWhy doesn't a handbook work?

For three reasons, and they stack.

You don't know what you know. Expertise has the property of becoming invisible as it grows. What you've done for fifteen years doesn't feel like knowledge, it feels obvious. Those very obvious things are exactly what a new employee is missing, and you don't mention them on your own, because you no longer see them.

Writing is a different craft than doing. Most people are considerably better at explaining than at writing. In a conversation you associate, give examples, correct yourself halfway. In front of a blank document you don't. You write the tidy version, and the tidy version misses the exceptions.

It's never finished. A handbook is done the day your way of working changes, and it changes constantly. So the maintenance stalls, and after a year nobody trusts the document anymore. A document nobody trusts doesn't get used, and then the time spent on it is wasted.

This isn't a discipline problem. It's a format problem. The solution isn't trying harder to write things down, but choosing a different format in which the knowledge actually comes out.

04 / the methodSo how do you actually get it out?

By talking and recording it. Not by filling in a questionnaire.

The difference is bigger than it sounds. A form asks what you think is important. A conversation where someone keeps digging exposes what you no longer see as special yourself. The question that does the work is almost never "how do you do this", but "why did you do it differently for that client".

The chain that follows isn't complicated, and it's worth knowing how it runs before you buy it from someone:

How those four steps run in practice for us is laid out at how it works. For whoever suffers most from this pattern: that's the knowledge entrepreneur, and that group is bigger than the term suggests.

Step 3 is where it stands or falls. Knowledge kept as one large document can't be maintained and can't be checked. Knowledge held in separate units with a source attached can be adjusted piece by piece when your way of working changes. That's the difference between an archive and a living system.

One rule, one source. What you can't trace back, you can't trust.

And watch the order. Software is step four, not step one. Whoever starts by picking a tool is choosing a format before knowing what needs to go into it. That's the reverse order, and it's the most common mistake in this whole topic. How to approach it the right way is in where to start with AI.

05 / the testHow do you know it worked?

By one thing: less comes back to you.

That's the only measure that counts, and it's sharper than it sounds. Not "we now have documentation", not "the system is live", but: the questions that landed on your desk last month no longer land there this month. If that doesn't happen, knowledge got captured that nobody needed.

Two useful in-between checks:

• Can someone else find the answer without you? Not "is it written somewhere", but: do they find it, and do they dare to act on it. That second part is a trust question, and you only win it with traceability.
• What happens with an exception? A system that handles the standard cases and stalls on every deviation has captured row 1 and left rows 2 and 3 on the table. Then you've built a handbook with better technology.

What you should not measure is how much is in there. Size isn't quality. A knowledge layer of two hundred sharp units is worth more than one with two thousand vague ones.

06 / the boundaryWhen should you not start this?

There are three situations where we'd say: don't do this now.

Your way of working isn't settled. If your offering changes materially every quarter, you're capturing a moving target. Waiting is then cheaper than building. This applies to young businesses more often than they think.

You're the only one and that's staying that way. If you work alone and want to keep working alone, the payoff is small. The gain from captured knowledge sits in transfer, and without someone to transfer it to you're mostly paying for a tidier archive.

The problem is capacity, not knowledge. If you're stuck because there's simply too much work and too few hands, this is the wrong tool. Capturing knowledge helps against repeat work and dependency, not against a calendar too full of work only you can do.

In all three cases we'd simply say so in a conversation. That's not modesty: building a system on a moving foundation gives you a system nobody trusts within a year, and that helps no one.

Further reading: why captured knowledge should stay yours is covered in whose is it once it works, and what such a system explicitly does not do is in what AI doesn't do.

This text was produced with AI assistance and reviewed and approved by a human before publication.