Why Nobody Writes Down What the Company Knows

There is one week that tells the truth about every company, and it is the week one colleague is on holiday.

Nothing dramatic happens. It simply turns out that you must never put a price in an email to the largest account, because on their side that counts as a purchasing request, and exactly one person knew this. It turns out that the supplier return form always has to be split in two, because the warehouse will not accept it otherwise. It turns out that a particular customer should not be called on a Friday afternoon. None of those three things was written down anywhere, because none of them ever felt important. The person who knew them was simply always there.

A company's operations are not built only on processes and tools. They are built on knowledge too, on how problems get solved, what the team has learned about particular customers, what worked before and what did not.

In most small and medium-sized companies, this knowledge sits in people's heads, scattered across emails, buried in old chat messages, or kept alive by the phrase “let's just ask someone”.

This works in the short term. Once the company starts growing, it turns into a serious drag.

Why nobody writes it down

Writing something down has a cost, and at the moment of writing, that cost always looks bigger than the benefit.

For the person who knows the answer, saying it takes thirty seconds. Writing it so that a different person can act on it takes ten minutes. The ten minutes hurt now, while the payoff only arrives the next time somebody needs it, and nobody can say when that will be. Anyone reasoning about their own day will choose to answer the question, every single time.

The second reason is more delicate. In a small company, knowledge held in someone's head is status, because the person you cannot do without is important, and that position is hard to give up voluntarily. Documentation starts happening where sharing knowledge becomes the thing the company recognises, rather than holding on to it.

When writing it down is not worth it

Not every piece of knowledge should be organised, and companies that try to capture everything usually capture nothing.

If a process changes every week, its description will always be out of date, and that is worse than having none, because whoever reads it will be wrong, and confidently so. Work like that does not need documenting. It needs stabilizing first, and documenting afterwards.

If something happens once a year and always by the same person, the cost of writing it down probably exceeds the benefit. A company does not know how to close its financial year because there is a document about it. It knows because somebody does it.

And if there are three of you in one room where everybody hears everything, knowledge sharing is already happening, just not in the form of documents. A knowledge base would add nothing except one more place where something can be forgotten.

Documentation starts paying off where the same question comes up for the third time, or where the answer is needed by someone who cannot simply turn around and ask.

The knowledge exists, it is just not accessible

Losing internal knowledge rarely happens dramatically. Nothing breaks overnight and no system collapses. Everything simply gets slower.

The signs are familiar. The same questions get asked again and again, new employees stay uncertain for weeks, experienced colleagues spend their days explaining things, and the reasoning behind decisions becomes impossible to trace. The knowledge exists. It is just not organised.

The last of those is the costliest, because it does not even look like something is missing. A year ago somebody decided that one customer does not get a shipping discount. Nobody knows why any more, only that “this is how we do it”. When a new salesperson arrives, they have two options. They can inherit a rule with no reason attached, or overrule it and run straight into whatever produced the rule in the first place. A company in that position cannot learn. It can only repeat.

The first week of a new hire is where it becomes obvious

Onboarding is usually the first place where this gap becomes visible.

A new employee cannot find the internal guidelines, the processes are unclear, there is no place where everything connects, and every small detail turns into a question. This is a system problem, not a learning curve, because the next person to join would run into the same thing.

It does not stop at them. Explaining things takes time away from the experienced colleagues, independence develops slower, and the chance of mistakes goes up.

There is a quieter consequence too. A new person quickly learns how many questions it is acceptable to ask in a day. Once they reach that limit, they stop asking and start guessing. Mistakes that come from guessing surface weeks later, by which point nobody can trace where they came from.

The knowledge base as company memory

The knowledge base is not a pile of documents and not another folder. It is searchable and categorised, and three things follow from that. Information has one valid version, knowledge is not tied to individuals, and experience stays in the company even when the person who had it moves on.

The goal of the IntrApp knowledge base is the same, so that knowledge gets into a system, can be found quickly, and needs nobody standing next to it explaining what it means.

What can be managed inside the knowledge base?

The knowledge base is where things like these live:

• internal process descriptions
• onboarding materials
• frequently asked questions
• customer management experiences
• technical documentation
• internal “how we do things here” guides

All of it can be categorised and structured, so that it does not turn into one long list where nobody finds anything a year later.

Not only useful for new employees

The knowledge base is not just an onboarding tool, and in most companies that is the larger part of its value.

In everyday work it shows up as two people giving the same answer to the same question. That sounds minor until the person asking is a customer. If three colleagues describe your delivery terms three different ways, the customer does not conclude that your team is diverse. They conclude that you do not know what you promised. A written, shared answer does not constrain people. It saves them from inventing one on the spot.

Knowledge and scalability

A company can grow when knowledge can be transferred and the way of working can be taught. While every piece of experience stays attached to a person, growth is fragile, because each new hire is a load on somebody and each absence is a risk.

This is the most common reason a smooth eight-person company starts to grind at twelve. The work did not get harder. What happened is that the operation used to fit inside four people's heads, and now it does not.

Why unwritten shared habits surface exactly when a new person joins is a separate article on the stages a team goes through.

What a separate file cannot tell you about itself

The trouble with separate files is that a document does not know what it belongs to. There is a note about supplier returns, but it does not say which supplier it covers, when it was written, or whether the agreement has changed since. The reader fills in that missing background by guessing.

Inside the knowledge base an entry is part of the system, so it can be linked to a task, a project or a customer, and it stays visible what it was written for. This is not additional administration. It is what keeps the entry readable a year later.

Written knowledge decays too

Fill a knowledge base once and never touch it again, and in two years you will be running a museum.

A knowledge base stays usable when maintaining it is a by-product of the work rather than a separate project. The habit that works most often is a simple one. Whoever answers a question they have already been asked before does not just send the answer, they write it down, and send the entry to the next person who asks. The second habit is ownership. Every entry has a named owner, so when something goes stale there is a person to ask, instead of a shared responsibility that belongs to nobody.

This matters because an outdated entry is worse than an empty page. Someone who finds nothing goes and asks a person. Someone who finds an answer that was correct two years ago acts on it.

When knowledge stops going home at night

Internal knowledge is not a secondary concern and not something to organise “someday”. Once it is in a system, the same question comes up less often, a new person becomes independent sooner, the way of working gets steadier, and the experience stays with the company even when the person who had it moves on.

IntrApp is not another program added to the end of the queue. It is the Business Operating System the company runs on, not a CRM and not an ERP, and the knowledge base is the memory of that foundation, sitting next to the tasks, the projects and the customers rather than somewhere separate. You can try it without risk, and if it is not right for you, you cancel it like a streaming subscription.

Knowledge only becomes valuable when it is accessible. A company is not made strong by having irreplaceable people in it. It is made strong when what those people know does not come to work with them.

Open the demo