How and Why to Organize an Information Repository and Knowledge Base

Why a company needs an internal knowledge base and how to properly organize a shared information repository.

How and Why to Organize an Information Repository and Knowledge Base
INGELLO / BUSINESS1804

Every family had someone who knew how to cook that one dish. Grandma's borscht, the holiday pie, the pickles nobody could replicate. There was no recipe; it lived in her hands. "Well, salt to taste, as much flour as it takes, keep it on until it's done." When that person was gone, the dish disappeared. Others tried, and it came out similar but not the same. The knowledge turned out to be tied to a single carrier, and the carrier turned out to be mortal.

Exactly the same happens in companies, only more often. An employee worked with a key client for three years, knew all his habits, all the agreements, why last time the price was settled exactly that way. The employee left. The knowledge left with him. The new person spends six months stepping on the same rakes, and the client wonders why he is once again discussing what was decided two years ago.

A chat is not a knowledge base

The first objection I usually hear is: "We have everything in our chats." Yes, You do. Somewhere. A chat is like a river: information flows past, and at the moment of discussion everything is clear. But a month later the message You need has been carried thousands of messages downstream. You can find it if You know exactly what to look for, when it was and who wrote it. In other words, if You already know the answer.

A knowledge base is a lake. The water stays put, You can scoop it up when You need it, and it will still be there tomorrow. The goal is not to stop using chats but to regularly move what matters from the river into the lake. A decision was made in a chat? Write it down where it will live. You answered a newcomer's question for the third time? That is a sign the answer should become an article.

Why business needs this, counting the money

It sounds like a matter of convenience, but in fact it is direct money.

  • Onboarding. A new employee with a clear knowledge base becomes useful many times faster. He does not pull colleagues away every half hour or wait until someone has time to explain.
  • Fewer repeated questions. Every question in a chat distracts at least two people: the one who asked and the one who answered. Multiply by the number of questions per day.
  • Work standards. Regulations, document templates, checklists. Once they are written down, quality stops depending on who happens to be on shift today.
  • Protection against people leaving. The company stops being hostage to specific employees. The value of knowledge stays inside even as people change.
  • Fuel for AI. This is a new and very important point. The AI assistants and agents now arriving in business answer exactly as well as the information they rely on. No knowledge base, and your assistant will politely make things up.
Knowledge that lives only in a head belongs to that head. Knowledge that is written down belongs to the company.

How to organise it so it doesn't become a graveyard

The most common fate of a corporate knowledge base: it is started with enthusiasm, filled in the first month, and a year later it is a graveyard of outdated documents nobody trusts. To prevent this, a few rules from practice.

First: the structure should be simpler than seems necessary. Do not build a tree of forty sections right away. Start with a few: how we work, clients and projects, products and prices, document templates, newcomers' questions. The structure should grow out of real use, not out of fantasies about the future.

Second: the base needs a gardener. Not necessarily a separate position, but a specific person responsible for keeping the garden from overgrowing. He does not write everything himself; he makes sure the outdated gets removed and the new appears. A garden without a gardener turns into a jungle within a year.

Third: recording knowledge is built into processes. A project closes, and a short summary goes into the base. An architectural decision is made, and it is written down with the reasons. A price changes, and the section is updated. If recording knowledge is a separate good deed done "when there's time", there will never be time.

Fourth: secrets are kept separately. Passwords, access keys and clients' personal data do not belong in the shared knowledge base. There are dedicated vaults with access control for them.

How it works at Ingello

At Ingello the knowledge base lives in a git repository as ordinary text files: regulations, case studies, prices, templates, process descriptions. This may seem a strange choice for a non-technical company, but it has its advantages. You can see the history of every change: who corrected what, when and why. The files are read both by people and by our AI agents, which prepare commercial proposals and answer standard questions. And the public part of this experience turns into articles on Business Ingello, where You are right now.

The tool is secondary. Notion, Confluence, a wiki, a folder of documents, a repository: everything works if there is discipline. Without discipline nothing works, not even the most expensive product.

What to do tomorrow

Ask each team member to write down, over one week, the three questions they are asked most often and the three questions they most often ask colleagues. Collect everything into one list. That is the first table of contents of your knowledge base. Answer the most frequent questions with short articles and put them where they are easy to find. And from next month introduce a simple rule: if You answer a question for the second time, the answer has to appear in the base. Grandma's borscht must outlive grandma.