- Home
- Learn
- Internal knowledge base
Internal knowledge base
How to keep an internal knowledge base accurate after six months
Setting one up takes a few weeks. Keeping it true is the part that decides whether anyone still uses it a year later — and it is the part most guides cover in a single line. This page is by the makers of SecondBrain 365, an AI agent inside Microsoft 365 that writes knowledge base pages from email, meetings and chats — and flags when a new fact contradicts a page.
What an internal knowledge base is
An internal knowledge base is the set of pages where a company writes down what its employees need to know to do their work: how processes run, what was decided and why, which policy applies, who owns what. Unlike a help centre it is written for colleagues, not customers; unlike a file archive it is meant to answer questions, not just to store documents.
If you are at the beginning, the problem is a different one — starting a company wiki from an empty page — and if what you need is one team's knowledge reaching the others, that is how knowledge gets from one team to another. This page is about what comes after: why a knowledge base that was right on launch day is quietly wrong a few months later, and what actually keeps it accurate.
Why an internal knowledge base drifts
It is rarely abandoned. It is outrun: the company keeps changing, and the changes happen somewhere else.
The change never passes through the page
A supplier changes, a threshold moves, a process gets a new step. It is decided in a meeting or announced in an email, and everybody in that room knows. The page that describes the old way is not in the room. Nobody lied and nobody was careless: updating it was simply a second job, after the real one, for someone who may not know the page exists.
A wrong page looks exactly like a right one
Nothing turns red when a page stops being true. The reader finds it, trusts it, and follows it — or has been burned once and trusts none of them. In Atlassian's survey of 12,000 knowledge workers, 56% say they often find that the only way to get the information they need is to ask someone or schedule a meeting, and the report notes that people who do find something usually have no way of knowing whether it is up to date.
That is the spiral: people stop trusting the pages, so they ask a colleague, so nobody reads the pages closely enough to notice what is wrong, so they get worse. Source: Atlassian, The State of Teams 2025.
What the usual advice catches, and what it misses
Every guide ends with the same recipe: assign owners, review regularly, watch the analytics. It is good advice. It is also worth knowing exactly which errors it finds.
- An owner and a review dateEvery page has a named person and a date to re-read it — quarterly, twice a year.
- CatchesPages nobody has looked at in a long time, and topics with nobody responsible.
- MissesThe change that happened last week. The review asks the owner whether the page still looks right, and the owner was not in every meeting where it stopped being right.
- Fix it when you use itWhoever reads a page and finds it wrong corrects it or flags it on the spot.
- CatchesErrors in the pages people actually open, while they are open.
- MissesThe error the reader cannot see. People open a page because they do not know the answer — which also means they cannot tell that the answer has changed.
- Check at the moment it changesWhen something is decided in an email or a meeting, someone compares it with what the knowledge base says.
- CatchesThe contradiction on the day it is born, with both sources side by side.
- MissesNothing in principle. In practice it needs someone in every conversation who also remembers every page, so nobody does it by hand.
The second approach has a name in IT support: the Knowledge-Centered Service method calls it “flag it or fix it”, and it works well for the pages people read every day. The first one is where most companies stop. In HDI's survey of 405 support organisations, 60% review every article when it is submitted — and 16% do not monitor their knowledge base at all (HDI, Knowledge Management in Technical Support, 2013). Checking a page when it is written is the easy part. It is also the one moment when the page is guaranteed to be right.
The third approach is the only one that looks where the change actually happens. That is why it is the one nobody manages to staff.
Four habits that keep pages honest
None of them needs new software. They make errors easier to see, which is most of the battle.
Link every fact to where it was decided
“Contracts under €10,000 need one approval” is a claim. With a link to the email where finance said so, it is checkable — by the reader who doubts it and by the owner who reviews it.
Date the fact, not the page
“Last edited three days ago” may mean somebody fixed a typo. What the reader needs is when the rule on the page was last confirmed.
Write each fact once
Contradictions are born from copies: the same rule on the onboarding page and on the policy page, and only one of them updated. Link to the page that owns the fact instead of repeating it.
Make “this is wrong” cheaper than asking a colleague
A comment, a button, a channel where a flag reaches the owner. If reporting an error takes longer than asking the person at the next desk, people ask the person — and the page stays wrong.
And retire pages on purpose: a page left in place keeps being found. If your company used Viva Topics, the topic pages it left behind are a case in point — what Viva Topics left in your tenant, and what can keep it current.
Where SecondBrain 365 fits
An agent that is in the room when the fact changes
SecondBrain 365 is an agent with its own identity and company email inside your Microsoft 365. You copy it on an email, invite it to a Teams meeting, add it to a Teams group or share a document with it — wherever you bring it in, what is said there becomes pages in a knowledge base on your SharePoint, linked to each other.
When something new contradicts what the knowledge base already says, it posts on Teams and asks which one holds. It does not overwrite the page on its own, and you can require approval before anything is written at all.
It only knows what it is shown. A change agreed in a corridor reaches the knowledge base when someone puts it in writing where the agent can read it. The mechanism, step by step, is on how it works; the difference from assistants that only answer is on an AI that writes documentation instead of only answering from it.
Elena Rota · Jan · KB page: Buying software
New software requests go through the IT ticket portal.
Davide Neri · 12 Sep · Email from IT to all staff
From 1 October, software requests go through the procurement form.
SecondBrain 365Agent
Inconsistency on “Buying software”
The page says requests go through the IT ticket portal. Today's email says the procurement form. Which one holds?
Where to request:the IT ticket portal
Until someone decides, the page keeps the IT ticket portal and the alert stays open.
A page written in January and an email sent this week. Without the alert, the page would keep sending people to the old queue.
Department knowledge bases are where this matters most. See it applied to an IT knowledge base kept by forwarding replies and to HR policy pages overtaken by an announcement.
FAQ
Questions about keeping an internal knowledge base current
By how fast the content changes, not by the calendar. A page about a stable policy can wait a year; a page about a supplier, a tool or a price should be checked whenever that thing changes. A fixed quarterly review finds pages that are old, which is not the same as pages that are wrong.
Each area needs a named owner — usually the team that runs the process the pages describe, not a central documentation team that has to ask them. But owning accuracy does not have to mean writing every change: the owner's job is to decide which version is right when two disagree.
The reader. An external knowledge base answers customers and is written to be safe to publish. An internal one answers colleagues, so it can hold procedures, decisions and context that never leave the company — which also makes its errors more expensive, because people act on them.
Often it is the same set of pages under a different name. “Wiki” describes the format — linked pages that anyone can edit; “knowledge base” describes the purpose — answering questions. The question that matters for either is whether anyone is keeping it true.
It writes from the email, meetings, Teams conversations and documents it is included in, so pages change as the work happens. When new content contradicts an existing page it asks the team on Teams which one holds instead of deciding. You can require approval before anything is written, and every page stays editable by hand.
In a SharePoint site in your own Microsoft 365 tenant, with your existing permissions and retention rules. The pages are ordinary SharePoint content, so Microsoft 365 Copilot can answer from them too.