How to build a knowledge base in 30 days: structure, sources, ownership — and the base that grows out of what the team already says (2026)

A knowledge base is the set of answers an organization gives more than once, written down once and kept where the person who needs the answer can find it without asking. "How do we invoice a distributor in Switzerland?", "what do we tell a parent whose child missed the deadline?", "which carrier for pallets to Morocco?" — the fourth time any of these is asked, the organization has a knowledge base whether it has built one or not. It just lives in one colleague's head and in a dozen chat threads.

Most guides to building one start with choosing software. This one starts earlier, because the software is the least of it: a knowledge base is three decisions — a structure, a set of sources, and a name on every entry — and a month of doing them in order. The 30-day plan below gets a 10–200-person organization to a base people actually open, with an entry template you can copy, a worked example, a table of where the base lives in the tools your team already runs on, and then the part most guides skip: the base is mostly already written, in what the team says in its meetings and types in its chats, and the job is to keep that in one place, readable by everyone on the team.

What a knowledge base is — and what it isn't

Four things get called a knowledge base, and the confusion between them is why so many are built and so few are used:

The knowledge base is the first row, and it depends on the other three. The wiki is what it becomes without structure; the document library is where its files live; the chat history is where most of its entries are first written, by accident, as replies. The craft is moving an answer from the fourth row to the first — once, with a name on it — and the method below is built around that move.

Two further distinctions matter before building. An internal knowledge base is for the team: how we do things, where things are, what we decided. An external one is for customers: how the product works, what to do when something fails. This guide is about the internal one; an external base is written from the internal one later, by rewriting the entries customers are allowed to see. And a knowledge base is not a process document or an SOP: those describe a whole job end to end; an entry answers one question and links to the procedure when the answer is "follow it".

The three decisions: structure, sources, ownership

Structure: by question, not by department. The person asking "how do we invoice Switzerland?" does not know whether the answer belongs to finance, sales or logistics; they know the question. A base organized by department sends them into three sections to find one answer. Organize by the questions people ask — in their words — and keep the top level to seven sections or fewer. Beyond seven, the structure itself needs a search, and a search over a base nobody has filled yet returns nothing. Typical top levels for a small organization: clients and orders; money and invoicing; people and hiring; tools and access; rules and decisions; who to call.

Sources: what already exists, before anything new. Nobody has time to write a knowledge base from a blank page, and nobody needs to. The answers exist — in the reply a colleague gave last Tuesday, in the recap of the meeting where the rule was set, in the price list someone attached to a message in March, in the onboarding notes the last new hire kept. The first version of most entries is copied, not written. Where the sources live, and how much of each is reachable later, is the subject of the table further down; the short version is that in most suites the chat, the files and the meeting notes are three separate places, and the meeting itself is the one that leaves the least behind.

Ownership: a name and a date on every entry. The single thing that separates a knowledge base people trust from one they stopped opening is whether an entry says who owns it and when it was last checked. An entry with a name and "reviewed 14 October 2026" is believed; the same text without them is "probably out of date". The owner's job is small: once a quarter, answer "is this still right?" and change the date. It is not rewriting the base. If nobody can be named for an entry, the entry is not knowledge; it is a guess, and it comes out.

How to build a knowledge base in 30 days

The plan assumes one person driving it — the team lead, or whoever gets asked the most questions — spending about two hours a week, and the rest of the team spending minutes.

Week 1 — collect the questions, not the answers. Open a channel, or a note in an existing one, and for seven days have everyone drop in every question they asked a colleague or were asked, in the words used. No answers yet. By Friday there are forty to eighty questions; a third are duplicates. Count the repeats: the question asked five times is entry one. The day before, where the list lives is also where the base will live; the choice of place is made here by what the team already opens every day, not by a software comparison.

Week 2 — the structure and the owners. Sort the questions into groups; the groups are the sections, and there are no more than seven. Name an owner per section — the person who answered most of its questions in week 1. Then name an owner per entry for the twenty most-asked questions. Write nothing yet except the list: section, question, owner. Send it to the team and ask one thing: "which questions are missing?" The list comes back with ten more.

Week 3 — the first twenty entries, from sources. Each owner writes their entries using the template below, starting from what already exists: the chat reply, the recap, the file. The rule for week 3 is "short and true beats long and complete": a two-sentence answer with a link to the file, dated and signed, is an entry. A page that explains the history of the rule is a document, and it can come later. Entries that depend on a decision nobody can find go into the decision log first, then into the base with a link.

Week 4 — publish, then run the loop. Pin the base where the team reads. Then set the two habits that keep it alive: every question asked in the question channel from now on gets an entry or a link to one, written by whoever answered it; and every entry's owner gets the review date in their calendar. Day 30 is not a finished base. It is twenty to thirty entries, each owned and dated, and a loop that adds one whenever a question is answered. Six months later it is two hundred, and nobody wrote it as a project.

What does not happen in the 30 days: migrating the document library, choosing a new tool, or writing a page for every process. The base points at files where they are and at procedures where they live. Moving them is a different project, and often an unnecessary one.

A knowledge base article template

One entry, one question, under a page. Copy it as a note and fill it in; the lines most often skipped are the last three, and they are the ones that keep the entry true.

[Question, in the words people use to ask it]
Owner: [name] · Section: [one of the seven] · Last reviewed: [date] · Next review: [date]
Short answer: [two sentences — what to do]
Applies to: [team, office, client type] · Does not apply to: [the case people confuse it with]
How: [numbered steps, each naming the system, person or file involved]
The rule behind it: [the decision that set it, with its date, and why]
Exceptions: [the cases off the normal path, and who decides each]
Where the files are: [link to the current template, price list, contract]
Related entries: [the SOP, the process, the previous version]

The template is plain text with bold labels, so it pastes into a Word file, a Google Doc, a wiki page, a Slack canvas or a chat note without reformatting.

A worked example: an exporter's base after 30 days

An Italian machinery exporter, 38 people, a sales office in Milan and distributors in Spain, Romania and Morocco. Week 1 produced 61 questions; after duplicates, 44. The structure that came out of them, with the number of entries per section at day 30:

1. Distributors and orders (7) — how a new distributor is set up; who approves a credit limit; what an order needs before it goes to production
2. Invoicing and payment (5) — invoicing a distributor in Switzerland; when a pro forma is used; what to do when a payment is 30 days late
3. Shipping and customs (6) — carriers by destination; the documents a pallet to Morocco needs; who signs the export declaration
4. Service and warranty (4) — what the warranty covers; how a service visit is booked; which parts are kept in stock
5. Tools and access (3) — who gives access to the CRM; where the price list lives; how to reach the shared mailbox
6. Rules and decisions (3) — the two-signature rule above 10,000; the discount ceiling; the decision log
7. Who to call (2) — the customs broker; the carrier contacts by country

Thirty entries. The most-asked question of week 1 — "which documents does a pallet to Morocco need?" — had been answered in the channel eleven times in a year by the same logistics lead; the entry took her twenty minutes, because the eleventh answer was already written and only needed the owner line and the date.

A filled-in entry from section 3:

Which documents does a pallet to Morocco need?
Owner: Logistics lead · Section: Shipping and customs · Last reviewed: 3 November 2026 · Next review: 3 February 2027
Short answer: Commercial invoice in three copies, packing list, EUR.1 certificate, and the distributor's import licence number on the invoice.
Applies to: all shipments to Moroccan distributors · Does not apply to: spare parts under 1,000 EUR by courier, which go with the courier's own form.
How: 1. Export the invoice from the system with the Morocco template. 2. Add the licence number from the distributor's file. 3. Request the EUR.1 from the chamber of commerce, three working days. 4. Attach the packing list. 5. Send the set to the customs broker and copy the distributor.
The rule behind it: The licence number was added after the March 2026 hold at Casablanca (decision log entry 2026-03-19).
Exceptions: Demonstration machines go under a temporary admission; the logistics lead decides.
Where the files are: Morocco invoice template; EUR.1 request form; distributor files.
Related entries: Carriers by destination; who signs the export declaration.

Where the knowledge base lives in the tools you already use

A 10–200-person organization builds its base in the suite it already pays for, and each suite has a place for the entry, a place for the files, and a path for what a meeting leaves behind. Each stops at a different point, and in each the record is in the language it was typed in. Documented behaviour only, from the vendors' own pages, with the month each page was checked:

Three things are the same in all four. The entry is a document or a message in the one language it was typed in, and a member who reads another language reads that or a copy someone made. The files are in a second place, found by a second search. And the meeting — where the rule was argued and set — reaches the base only when a person types it in afterwards: where Teams and Meet keep a transcript and a summary at all, and how to keep them after the call, is in where Microsoft Teams and Google Meet store your transcript, recording and summary; the AI notetakers many teams add for the same reason are compared in Otter.ai alternatives, and each of them writes its summary in one language.

The translation these suites document belongs to the call or to the reader's screen, not to the record: Microsoft documents live translated captions in Teams meetings when the organizer holds a Teams Premium or Microsoft 365 Copilot license, Google documents translated captions in Meet on eligible Workspace plans (both checked August 2026), and WhatsApp documents translating a received message on the reader's phone (checked August 2026) — what each covers and where each stops is in Microsoft Teams live translation, Google Meet live translation and WhatsApp translate. The entry the distributor's clerk in Casablanca opens on Monday is a separate object from those captions, and it is read in the language it was typed in.

The base that grows out of what the team already says

InterMIND is a communication space where a team's work lives in a channel, so the knowledge base has an obvious home: the channel of the team that uses it — the export team, the clinic's front desk, the agency's account group — and that channel is also the question channel and the place the meetings start from. The three decisions above map onto it directly.

Structure and ownership are the entries themselves. Posted as a note — a rich-text message with headings and numbered lists, edited later from its own menu — an entry is read by each member in their own language with the original a toggle away, and pinned so the current version is the first thing a new colleague finds; with edit history switched on, the earlier wording of a changed rule appears above the current text as a word-level diff with its timestamp, which is the review trail the owner's "last reviewed" line points to. The files an entry points at — the price list, the Morocco template, the distributor contract — are uploaded to the same channel and carry, on every plan, an AI summary in the reader's language with each point linked to the paragraph it came from; on paid plans the file itself opens translated into the reader's language (30 languages for documents). If the master copy stays in a document tool, its updates land in the channel by email: the channel's host gives it an address of its own, and a message sent there appears as a regular message with the sender named and attachments kept. A team arriving from Slack brings its channels with it: a standard Slack workspace export restores as one channel per Slack channel, messages in order with their original timestamps, pins and reactions kept, each message read by every member in their own language.

Sources are where the channel does the job the table above leaves to a person. The meeting where the rule is set starts from the channel; during the call the draft entry goes on everyone's screen next to the video tiles with Share to conference — a note, or a Google Docs or OneDrive document linked in the chat — and each participant scrolls it independently and reads it in their own language, while the sharer edits it live. When the call ends, the recap is written from the meeting itself — a summary, the points marked agreed, open or disputed, the action items with owners, each line keeping its timestamp — and the documents shared during the session contribute their summaries alongside what was said. It arrives by email, as a message in the channel and as a link in the calendar event, and every signed-in member reads it in their own language: the record is translated per reader, not written once in the language the room happened to use. Any member can edit it, every edit keeps author and revision history, and the channel keeps the recap of every past session — so the meeting that set the Morocco rule is one click from the entry that states it. That is the base growing out of what the team already says: the eleventh answer in the channel, the recap of the call where the rule was argued, the file attached in March, all in one place, with the entry on top of them.

The question channel gets the same treatment from the other direction. A member's own assistant — Claude, ChatGPT, Copilot or Gemini, connected through the MCP connector — searches recaps, transcripts, chats and the text of shared files in one question, "which documents does a pallet to Morocco need?", and returns the passages with the meeting, the date and the file each comes from; this runs for organizations with AI features on, and reading through the assistant is limited to the meetings and channels the member is in. The chat itself has a search, and the base can be taken out whole: on every plan a backup from Settings exports the channels as a ZIP with their messages, transcriptions and files, which is the ownership question answered at the level of the organization rather than the entry. Set next to the table above, the difference is a plain statement of fact: the captions those suites document translate the call while it runs; here the entry, the meetings that produced it, its files and its history are one record, read by each member in their own language.

The people who hold a team's knowledge are not always employees. The distributor's order clerk, the customs broker, the freelance accountant who knows the Swiss rule: an external member of the channel joins by email onto a free account and reads the entries and their history like everyone else; a person without an account is a guest of one meeting — they join the call by link, from a phone, at no cost, hear it live in their own language, and get no record afterwards. The host provides the space and, on a paid plan, pays only for the members active in the previous 28 days — joined a meeting, wrote in a chat or asked the assistant; members who go quiet keep their access at no cost, which is what a knowledge base needs: the person who wrote the entry two years ago can still be in the channel.

• Open a complete recap — a real record rendered by the same code that writes yours.
• Try the live demo — no signup; speak, and hear the room translated per listener.

Building a knowledge base as a craft survives every tool: somebody still has to collect the questions, keep the structure to seven sections, put a name and a date on every entry, and answer in the channel instead of by direct message. What does not have to survive is the second job — retyping what the meeting decided into the base, and keeping a translated copy of every entry by hand, one language at a time, for the office that reads the other one.

FAQ

What is a knowledge base?

A knowledge base is a collection of answers to the questions an organization gets asked more than once, written down once, each with an owner and a date, and kept where the person who needs the answer can find it without asking a colleague. An internal knowledge base answers the team's own questions — how we invoice, where the files are, what we decided; an external one answers customers' questions about a product. It differs from a wiki in having a structure and owners, and from a document library in holding answers rather than files.

How do you create a knowledge base?

Collect the questions the team actually asks for one week, in the words used; group them into no more than seven sections; name an owner for each section and for each of the twenty most-asked questions; have the owners write those entries from what already exists — chat replies, meeting recaps, files — using a one-page template with a short answer, steps, exceptions and a review date; publish in the place the team already reads; then keep the loop running, where every answered question becomes an entry and every entry's owner reviews it on its date.

What should a knowledge base include?

One entry per question, each with the question in the words people use, an owner, the date it was last reviewed and the next review date, a short answer, the cases it applies to and does not apply to, the steps naming the system or person involved, the decision behind the rule with its date, the exceptions and who decides them, links to the current files, and links to related entries. The base as a whole needs a structure of seven sections or fewer, organized by the questions asked rather than by department.

What is the difference between a knowledge base and a wiki?

A wiki is a set of pages anyone can write in any structure; a knowledge base is organized by the questions people ask, with one entry per question and a named owner and review date on each. A wiki can be turned into a knowledge base by adding the structure and the owners; without them, a wiki grows into hundreds of pages that nobody can navigate and nobody has checked. The software is often the same; the difference is the two decisions.

How do you structure a knowledge base?

By question, not by department: the person asking does not know which department the answer belongs to, but knows what they are asking. Group the questions collected in the first week into no more than seven top-level sections — for a small organization typically clients and orders, money and invoicing, people and hiring, tools and access, rules and decisions, and who to call — and keep each entry to one question. If a section grows past about thirty entries, split it by the questions people ask rather than by who answers them.

How long does it take to build a knowledge base?

Thirty days to a base people open: one week collecting questions, one week on structure and owners, one week writing the first twenty entries from existing sources, one week publishing and setting the review loop. The driver spends about two hours a week; each owner spends twenty minutes per entry, because most entries are copied from an answer already given rather than written new. The base is not finished at day 30; it grows by one entry each time a question is answered.

Can you build a knowledge base for free?

Yes — the template in this guide is plain text, and the base can live in a note, a document or a channel in the tools a team already uses: a canvas in Slack, a Google Doc, a Teams channel's Files tab, a pinned note in a chat. What costs nothing in software still costs the owners' review time, and the limits are the suite's own: Slack's Free plan keeps 90 days of message history, and in every suite the entry is in the language it was typed in. In InterMIND the Basic plan is free, and pricing for paid plans is on the pricing page.

Sources: Microsoft Learn — Teams and SharePoint integration; Microsoft Learn — Learn about retention for Teams; Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Translate a message in Microsoft Teams; Microsoft — Use live captions in Microsoft Teams meetings; Slack — Pricing; Slack — Customize data retention in Slack; Slack — Export your workspace data; Slack — Meeting agenda template (canvas); Google Chat — Use Automatic Translation in Chat; Google Meet — "Take notes for me" in Google Meet; Google Meet — Use translated captions; WhatsApp — How to export your chat history; WhatsApp — Privacy policy; WhatsApp blog — Introducing message translations. The Microsoft Learn Teams–SharePoint page checked November 2026; the Teams retention and meeting-notes pages, the Slack canvas template page and the Google "Take notes for me" page checked October 2026; the Teams message-translation and captions pages, the Slack pricing, retention and export pages, the Google Chat translation and Meet captions pages and the WhatsApp pages checked August 2026. Vendors change plans, features and language lists over time; check their pages for the current state.