Make knowledge useful
How to build an internal knowledge base your team will actually use
An internal knowledge base is a place where your team can find the information it needs to do its work. It can contain methods, agreements, decisions and instructions. The useful part is being able to find the right version and understand when it applies. Start with a recurring question your team struggles to answer.
Build around questions people actually need to answer, then give the important records an owner and a way to stay current.
Choose the question people keep asking
Think about the last time someone needed help from a colleague. Was it finding the current client agreement, understanding why a decision was made, or working out what to do when a request falls outside the usual service? That question tells you what the first part of the knowledge base needs to contain.
Collecting every file at once makes the project larger without showing whether anyone can do useful work with the result. Choose a question with a clear user and a recognisable answer. Then find the few sources that answer it.
For example, someone covering an account meeting may need current goals, the agreed service, recent decisions and open issues. A folder of every presentation the firm has ever made would still leave them hunting for those four things.
Create a structure that matches the work
| Area | What belongs here | Who keeps it current |
|---|---|---|
| Shared methods | How the firm performs an agreed job, including exceptions. | Person responsible for that method. |
| Client context | Current goals, agreements and decisions for one client. | Person responsible for the account. |
| Work records | Approved output, changes and outstanding questions. | Person leading that piece of work. |
| Instructions | How to use a system or complete a repeat task. | Person responsible for the system or task. |
Shared methods and private client records have different audiences. Keep those access rules visible. A team member who can read a general reporting method does not automatically need access to every client’s figures.
Use names people recognise. A title such as “Client A reporting agreement, current version” is more useful than “Final deck v7”. Add the owner and the source link so a reader can check the original when the answer matters.
Keep origin and dates with the information
In our current knowledge build, we keep information about where a record came from separately from when it was valid. We also track when it was recorded. Those dates answer different questions: an old agreement can be collected today and still describe the wrong service.
Said describes confidence falling when information has not been seen again by its recorded validity date. That is a reminder to check the record, rather than a statistical guarantee that a newer answer is true. A person still needs to resolve important disagreement.
You can apply the same discipline in an ordinary knowledge base. Give important records a source, an owner and an appropriate review rule. A stable method may need review when the service changes. A client’s open issues may need review before each account meeting.
Test whether another person can use it
Ask someone who did not organise the material to answer the chosen question. Watch where they search, which version they choose and what they still have to ask. Give them the same access they would normally have.
A good test includes an older record and an incomplete request. You want to find out whether the person recognises a gap, rather than whether they can produce an answer to everything. Record where the structure or the information let them down.
Our current build has helped a person unfamiliar with an account get enough context to cover a colleague’s meeting. Said reported that one person obtained enough context in as little as 30 minutes. That is one reported example, with no previous-time baseline; it is not a promise for a new knowledge base.
Use the inventory to make a small first version
Worked example
Context for an account meeting
Invented teaching example. No client outcome is claimed.
QUESTION
What has this client agreed, and which issues need a decision at the next meeting?
FIRST COLLECTION
Current agreement, approved goals, recent decision notes and an open-issues record.
The account owner confirms which agreement is current.
FINDING AND ACCESS
A client page links to those four records.
Only the relevant account team can read the private client page.
TEST
A colleague follows the links and prepares a meeting brief.
If a decision has no recorded owner or evidence, it goes back to the account owner.
UPKEEP
A reviewed meeting decision updates the decision record.
The account owner checks open issues before the next meeting.
Add search or AI when the foundation is useful
An existing shared drive, intranet or document system may be enough for the first version. Choose a different tool when you have a specific gap, such as searching across systems or answering a question from several records.
An AI knowledge base adds a way to retrieve relevant material and prepare an answer. It still needs the same owners, dates and access rules. A useful answer should lead the reader back to the records that support it.
Further reading
Written by Said Lopez, founder of LeverageAI and author of Lean AI. Our guides draw on the method in the book and our work with clients.