Internal wiki: tools, structure, and the wiki that grows out of the channel history (2026)

An internal wiki is the set of pages an organization writes for itself and nobody else: how a new distributor is set up, where the current price list is, what was decided about discounts in June, who to call when the carrier is late. It is internal because the reader is a colleague, and it is a wiki because any member can write a page and any page can link to another. A 10–200-person organization has one the day a second person asks the same question — the only choice is whether the pages exist or the answer lives in one colleague's head and a dozen chat threads.

Most guides to internal wikis are lists of software. This one starts earlier, because the tool is the smallest of the decisions: a wiki that works is a structure people can navigate, a page format that stays true, and a place the team already opens every day. The craft comes first — the structure, a page template you can copy, a worked example from a clinic — then the mechanics: where the wiki lives in the tools your team already runs on, by their own documentation, and what each one does with the meeting where the rule was actually set. Because the test of a wiki is not the day it is launched. It is the Monday a new colleague opens it and finds the page in a language they read.

What an internal wiki is — and what it isn't

Four things get called a wiki, and the confusion between them is why so many are built and so few are opened:

The wiki is the first row, and it is the one the other three depend on. A knowledge base is a wiki with the structure enforced: one entry per question and an owner on each; the method for building one in 30 days is in that guide, and this one is about the wiki's own form. The intranet is what the wiki becomes when only three people are allowed to write. The shared drive is where the wiki's files live, and the wiki's job is to point at the current one. A wiki is not a process document or an SOP either: those describe one job end to end; a wiki page says where to find them and what changed since.

What makes a wiki internal is not a password. It is that the pages are written in the words the team uses — "the Casablanca rule", "the Tuesday run" — and that they can say what an external page never could: who decided, why, and what it replaced.

The structure: seven sections, one page per question

The difference between a wiki people open and one they stopped opening is rarely the tool. It is three decisions made, or not made, before the first page.

Sections by question, not by department. The colleague asking "how do we invoice a distributor in Switzerland?" does not know whether the answer belongs to finance, sales or logistics; they know the question. A wiki organized by department sends them into three sections to find one page. 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 wiki 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.

One page per question, under a screen. A page that answers one question gets found and gets read; a page that explains a whole function gets bookmarked and skimmed. "How do we invoice Switzerland?" is a page. "Finance" is a section. If a page needs a table of contents, it is two pages.

An owner and a date on every page. A page that says who owns it and when it was last checked 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 — and it is the single thing that keeps a wiki alive past its first year. A page nobody can be named for is not knowledge; it is a guess, and it comes out.

Two habits keep the structure once it exists. Every answer given in the team's channel that gets asked twice becomes a page, written by whoever answered it, linked from the section it belongs to. And every decision that changes a rule gets its line in the decision log first, then the page that states the rule links to it — so six months later the page can say not only what the rule is but why.

How to create an internal wiki in a week

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

Day 1 — pick the place by where the team already reads. Not by a software comparison. The wiki lives where the questions are asked: the team's channel, the suite the files are already in. A wiki in a fifth tool with its own login is a wiki nobody opens on a Monday morning. The table further down says what each place keeps and where each stops.

Days 1–3 — collect the questions, not the answers. Post one message in the channel: "Reply with every question you asked a colleague this week, in the words you used." By day three there are forty to sixty; a third are duplicates. Count the repeats: the question asked five times is page one.

Day 4 — sort into seven sections, name the owners. The groups the questions fall into are the sections. Name an owner per section — the person who answered most of its questions — and an owner for each of the first fifteen pages. Write nothing yet except the list: section, question, owner. Send it back to the team with one question: "what is missing?"

Days 5–7 — the first fifteen pages, from what already exists. Each owner writes their pages with the template below, starting from the chat reply, the recap of the meeting where the rule was set, the file attached in March. The rule for the first week is "short and true beats long and complete": a two-sentence answer with a link to the file, dated and signed, is a page. Then pin the section index where the team reads, and the wiki exists.

What does not happen in the week: migrating the shared drive, writing a page for every process, choosing a new tool. The wiki points at files where they are and at procedures where they live.

An internal wiki page template

One page, one question, under a screen. 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 page 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 reason — link the decision log]
Exceptions: [the cases off the normal path, and who decides each]
Where the files are: [link to the current template, price list, contract]
Related pages: [the SOP, the process, the previous version of this page]

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: a clinic's wiki after one week

A physiotherapy clinic in Barcelona, 24 people: a front desk of four, fourteen therapists, two in billing, the rest administration. Half the therapists came from Argentina, Colombia and Ukraine in the last two years; a third of the patients are British and German residents who book in English. Three days of collecting produced 52 questions; after duplicates, 37. The structure that came out, with the pages per section at day seven:

1. Patients and bookings (5) — how a first appointment is booked; what to do with a no-show; how a patient changes therapist
2. Billing and insurance (4) — which insurers are billed directly; how a receipt for a foreign insurer is issued; when a session is refunded
3. Treatment protocols (3) — where the protocol sheets live; who signs off a treatment plan; what is recorded after each session
4. Tools and access (2) — who gives access to the booking system; where the patient-letter templates are
5. Rules and decisions (2) — the 24-hour cancellation rule; the decision log
6. Who to call (1) — the insurers' contacts; the equipment service line

Seventeen pages. The most-asked question — "how do we issue a receipt a German insurer will accept?" — had been answered at the front desk nine times in a year by the same billing lead; the page took her fifteen minutes, because the ninth answer was already written in the channel and only needed the owner line and the date.

A filled-in page from section 2:

How do we issue a receipt a foreign insurer will accept?
Owner: Billing lead · Section: Billing and insurance · Last reviewed: 6 November 2026 · Next review: 6 February 2027
Short answer: Use the "insurer receipt" template, in the patient's language, with the diagnosis code and the therapist's licence number on every line.
Applies to: patients paying themselves and claiming from an insurer abroad · Does not apply to: insurers we bill directly, who get the monthly statement.
How: 1. Open the patient in the booking system. 2. Choose the insurer receipt template. 3. Add the diagnosis code from the treatment plan. 4. Check the licence number is on each line. 5. Send as PDF and file a copy in the patient's folder.
The rule behind it: Licence numbers were added after the German refusals in April 2026 (decision log entry 2026-04-22).
Exceptions: A patient who needs an itemized receipt per session asks the billing lead; nobody else issues one.
Where the files are: Insurer receipt template; diagnosis code list; patient folders.
Related pages: Which insurers are billed directly; when a session is refunded.

Where the wiki lives in the tools you already use

A 10–200-person organization builds its wiki in the suite it already pays for, and each suite has a place for the page, a place for the files, and a path for what a meeting leaves behind. Each stops at a different point, and in each the page 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 page 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 wiki 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 page: 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 receipt page the Ukrainian-speaking therapist opens on Monday is a separate object from those captions, and it is read in the language it was typed in.

The wiki that grows out of the channel history

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

The pages and their owners are notes in the channel. A note is a rich-text message with headings and numbered lists, edited later from its own menu, and it is read by each member in their own language with the original a toggle away; pinned, the section index 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 — the review trail the owner's "last reviewed" line points to. The files a page points at — the receipt template, the diagnosis code list, the insurer 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.

The history behind every page is 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 page 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 licence-number rule is one click from the page that states it. That is the wiki growing out of the channel history: the ninth answer at the front desk, the recap of the call where the rule was argued, the template attached in April, all in one place, with the page on top of them. 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 page, the meetings that produced it, its files and its history are one record, read by each member in their own language.

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, "how do we issue a receipt a German insurer will accept?", 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 wiki can be taken out whole: on every plan a backup from Settings exports the channels as a ZIP with their messages, transcriptions and files — the ownership question answered at the level of the organization rather than the page.

The people who hold a team's knowledge are not always employees. The insurer's claims contact, the equipment technician, the freelance accountant who knows the German receipt rule: an external member of the channel joins by email onto a free account and reads the pages 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 wiki needs: the person who wrote the page 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.

An internal wiki 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 page, 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 wiki, and keeping a translated copy of every page by hand, one language at a time, for the colleagues who read the other one.

FAQ

What is an internal wiki?

An internal wiki is a set of pages an organization writes for its own members — how things are done, where files are, what was decided and why — kept in one place, where any member can write a page and any page can link to another. It differs from a public wiki in its reader, a colleague rather than a customer, and from an intranet in that the people who do the work write and update the pages rather than a central team. The pages that get opened are the ones organized by the questions people ask, with an owner and a review date on each.

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

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 becomes a knowledge base by adding the structure and the owners; without them it grows into hundreds of pages nobody can navigate and nobody has checked. The software is often the same, and the method for turning one into the other in 30 days is in how to build a knowledge base.

How do you create an internal wiki?

Pick the place by where the team already reads, not by a software comparison; collect the questions the team actually asks for three days, in the words used; sort them into no more than seven sections and name an owner per section and per page; write the first fifteen pages from what already exists — the chat reply, the meeting recap, the file — using a one-page template with a short answer, steps, exceptions and a review date; pin the section index where the team reads. Then keep the loop: every question answered twice becomes a page, and every page's owner reviews it on its date.

What should an internal wiki include?

One page 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 pages. The wiki as a whole needs a structure of seven sections or fewer, organized by the questions asked rather than by department, and a section index pinned where the team reads.

What is the best tool for an internal wiki?

The one the team already opens every day, because a wiki in a fifth tool with its own login is the wiki nobody checks on a Monday. In Microsoft Teams the pages and files sit in the channel and its SharePoint site, with meeting notes as a Loop component; in Slack a canvas in the channel; in Google Workspace a Google Doc linked from the calendar; in WhatsApp the group chat itself — each with the documented limits in the table above, and each keeping the page in the language it was typed in. InterMIND keeps a team's notes, files, chat and meeting recaps in one channel, read by each member in their own language, next to those tools rather than instead of them.

Can you build an internal wiki in Microsoft Teams?

According to Microsoft's documentation, a team's files are stored in a SharePoint site created with the team, with all standard channels sharing that site and one folder per channel, so the channel's Files tab is where wiki documents live; meeting notes are a Loop component any attendee or organizer can edit, saved automatically and reachable from the Teams calendar and the meeting recap. Two documented limits matter for a wiki: external attendees cannot access or edit the meeting notes, and chats and channel messages can be deleted after a period by a Teams retention policy, while files follow their own SharePoint and OneDrive policies (pages checked October and November 2026).

How do you keep an internal wiki up to date?

With an owner and a review date on every page, and nothing else. The owner's job is to answer "is this still right?" once a quarter and change the date; a page whose owner has left gets a new owner or comes out. Two habits feed the pages: every answer given twice in the team's channel becomes a page, written by whoever answered, and every decision that changes a rule is logged first, so the page can link to why it changed. A wiki kept this way grows by one page whenever a question is answered, and nobody rewrites it as a project.

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.