What does a knowledge leak cost? A cost model for 25 to 100 employees

A knowledge leak never appears on an invoice. Yet you pay for it every week, in the hours people spend looking for something that already exists. This article gives you the model to work out that cost yourself, with an example for an organisation of sixty people, and the reason you should not call the result a saving.

What exactly is a knowledge leak?

A knowledge leak is knowledge that exists in your organisation but cannot be used at the moment someone needs it. It sits in the head of a colleague who is stuck in a meeting, in a mailbox you cannot access, in the fourth version of a document, with nobody sure which version is current, or in a folder you just don't happen to think of.

So the leak is not in what you know. It is in what you can find at the right moment. That distinction matters, because it explains why "storing more" doesn't solve the problem and sometimes even makes it worse.

Where exactly does the time leak away?

Four places, in order of how visible they are.

Searching. The most measured and the least discussed. McKinsey Global Institute research found that knowledge workers spend an average of 1.8 hours a day looking for information. That is almost a full working day a week, before anyone has done anything at all with what they found.

Asking again. The question that isn't put to a system but to a colleague. It costs twice: your waiting time and their interruption. For the experienced colleague who knows everything, that quickly adds up to half a day a week spent answering questions that could have been written down somewhere.

Onboarding. When a new knowledge worker takes months to work independently, the problem is usually finding the information they need, not learning the job. What they are missing isn't written down anywhere; they have to distil it from conversations.

Starting from scratch. Every document that starts blank while three similar ones already exist. Every proposal that doesn't build on the last one. This is the most expensive category and also the least visible, because nobody records the work they end up doing twice.

The cost model

Keep it simple and conservative. One formula, four variables:

A few choices keep the model defensible:

• Knowledge workers, not all employees. Only people who spend most of their day working with information. In an organisation of sixty, that is often forty, not sixty.
• 46 working weeks, not 52. Annual leave, public holidays and sick leave come off.
• Internal hourly cost, not your client rate. What an hour costs your organisation, not what you bill for it. Otherwise you inflate the estimated cost.
• A range, not a single figure. Work out the low and high end separately. "Between X and Y" is more credible than one precise amount, and you don't have to defend it to the last decimal.

For the hours lost, use what your team recognises, not what the research says. Our rule of thumb:

Want to use our cost model? Try the knowledge leak scan (in Dutch). You enter your own number of knowledge workers and what one hour of your team's time costs your organisation. The scan turns your answer about lost search time into an indicative cost range per year.

Those ranges are deliberately well below the 1.8 hours a day from the research. That is not a contradiction: the research counts all time spent working with information, while this question counts only the times someone actually gets stuck searching for it. Better to work with the number your own team recognises.

An example: a 60-person service provider

Take a service provider with sixty employees, forty of whom are knowledge workers. When asked how often they spend more than ten minutes searching, the team says "a few times a week". So we use 1 to 2 hours per person per week. The internal hourly cost is €100.

• Lower bound: 40 × 1 × €100 × 46 = €184,000 a year
• Upper bound: 40 × 2 × €100 × 46 = €368,000 a year

That is 1,840 to 3,680 lost hours a year.

That covers searching alone. The other three categories are not included.

The amount is big enough to make people uncomfortable, and that is exactly the point. Not because you will earn that money back, but because it shows this is a substantial problem. Two hours a week per person feels like nothing. Multiplied by forty people and a full year, it is a full-time salary that appears nowhere in the budget.

Why this is not a saving you can promise

This is where most business cases fall apart, so let's say it plainly: these are friction costs you already incur, not savings you can expect to pocket tomorrow.

Three reasons.

Time doesn't disappear, it shifts. If someone spends an hour less searching, that hour goes to other work. That is a gain, but it does not free up cash. Present it as a saving and at the first review someone will ask where that €368,000 went.

No system brings friction down to zero. A realistic improvement takes away part of the search time, not all of it. Estimate a partial improvement and make that assumption explicit.

Working faster does not necessarily create more breathing room. This is the paradox we often see in practice: you become ten times faster, but you also do ten times as much. The space that opens up fills with heavier work. That is a good trade, but it doesn't feel like time saved, and time saved is what your team will expect if that is how you sold it.

So use the amount the way it is meant: as a measure of the size of the problem, along the lines of "this much money is tied up in the problem year after year, so even a 25 per cent improvement is serious money".

What does waiting cost?

More than you think, because the cost of delay is not linear.

Investing in how you organise company knowledge works like compound interest. Two hours spent capturing context you need every week pays off again every single time after that. If you then capture how your best account manager handles a hesitant client, that investment keeps paying off with every new colleague. Each deposit makes the next one more valuable.

It also means that every month you don't start, you don't just lose that month. You lose the return that month would have generated afterwards. And you start later on a bigger clean-up, because in the meantime more documents and versions have accumulated, and more colleagues have left.

The most expensive sentence in this whole story is: "We don't have time for that right now."

Where do you start?

Not with a big clean-up project. That is exactly the project that never gets finished, while the costs in the model above keep adding up.

Start with three steps that together take one afternoon:

1. Collect the twenty questions that come up every week. Ask your team, or look through the chat history where colleagues ask each other things. These recurring questions, rather than your folder structure, show which company knowledge to tackle first.
2. Assign one source to each question. Which document applies, who owns it, when it gets reviewed. Nothing more. Twenty rows in a table.
3. Measure for one week how often those questions still end up with a person. That number is your baseline, and it is also the only figure you can use later to show that something has changed.

Whatever you build after that, whether it is a curated knowledge layer or something simpler, stands or falls with those twenty rows. Without a designated source, every system keeps guessing which version is right, however clever the model on top of it.

The test you can run this afternoon

Ask two colleagues from different teams a question you know the answer to for certain. For example: what is our delivery time, or are we allowed to give this discount?

Do you get the same answer twice, with the same source? Then not much is leaking.

Do you get two versions, or "I'll need to check" twice? Then you have seen the problem the cost model measures, and you have the first of your twenty questions.