Company wiki
How to start a company wiki that isn't empty on day one
A new wiki is rarely killed by the wrong tool. It opens with a structure and no answers; people look once, and go back to asking a colleague. SecondBrain 365, an AI agent inside your Microsoft 365, fills the first pages from the answers already sitting in email, meetings and chats.
The short answer
A company wiki — also called an internal wiki — is a set of linked pages where employees write down how the company works: processes, decisions, who to ask, the answers to the questions that keep coming back. Anyone with access can add to it, which is what makes it a wiki rather than a folder of documents.
To start one that people actually use, do not start with the company and do not start writing. Start with one team and one owner, use the questions that team is asked as the structure, and fill the first pages with answers that already exist in email, meetings and chat. Open it only when it can answer those questions, and from then on reply with links instead of explanations.
Why most company wikis die empty
Not for lack of goodwill. A new wiki asks people to explain, a second time and somewhere else, something they have already explained once.
The explanation is given where the question arrives: in a reply, in a meeting, in a chat. Putting it on a wiki means stopping, restructuring it for readers you cannot see, and publishing it somewhere nobody asked for it. That is a favour to a future colleague, and it competes with work that has a deadline.
When researchers at MITRE studied how its staff used internal wikis, that is what they heard. Emailing something to a small group happens in the normal course of work; structuring a wiki entry is extra. People held back pages until they felt “finished”, and kept using the tools already in front of them. In the largest wiki, with 1,502 registered users, about 220 people made a change in an average month — roughly 3% of the staff.
A wiki that opens empty makes this worse. The first visitors search, find nothing, and conclude the answer is not there — a conclusion they do not revisit when, weeks later, it is. For knowledge that stays locked in one team for other reasons, see getting knowledge out of team silos.
3%
of staff edited the organisation's largest internal wiki in an average month.
“I would email demo instructions and put them in the code base but never [remembered to] put them on the wiki.”
A launch plan that starts from what already exists
Five steps over about a month. None of them needs new software, and the writing is mostly copying.
Before you open it
Pick one team and one owner
Start where questions repeat every week — IT, HR, a department, a long project — not with the whole company. Name one person who decides where a page goes and which version is right when two disagree. They do not have to write everything; they have to decide.
Week one
Write the structure as the questions people ask
List the questions that team answered most often last month, in the words people used. Each one is a page title. Group them into three to five sections at most. A page tree designed for content you do not have yet is the blank page in another form.
Weeks one to three
Fill it from what is already written
Most of those answers exist already: in sent emails, meeting notes, chat threads, the document everyone forwards. Copy them in, lightly edited, with the date and a link to where they came from. Open the wiki only when every question on your list has a page.
Launch day
Open it with an answer, not an announcement
An email saying “we have a wiki now” is read once. The next time someone asks one of those questions, reply with the link to the page. That is how people learn the wiki has the answer — and where it is.
From then on
Decide where new answers go
One rule is enough to keep it growing: an answer given twice goes on a page. Without a rule, the new explanations go back to email and chat, and the wiki stops at the day you launched it.
After the first month the problem changes: the pages exist, and the question becomes whether they are still right. That is a different job — keeping an internal knowledge base accurate over time.
Where the first pages are already written
If your company runs on Microsoft 365, the answers for week one are in four places. None of them is a wiki.
Sent itemsin Outlook
The reply you have written to three different people. If you explained it three times, it is a page — and the explanation is already tested on real readers.
Meetings and channelsin Teams
The recap someone circulated, the thread where an exception was settled, the message pinned because everybody kept asking. It is often where the decision was actually made.
Team sites and shared foldersin SharePoint
The procedure written for an audit, the checklist in a folder nobody browses. It exists; it is just not where anyone would look for it.
The document everyone forwardsin Word
The onboarding notes a colleague wrote for the last new hire and sends to every new one. That forward is a sign the page is missing.
If your company used Viva Topics, add a fifth place: the topic pages it generated may still be in your tenant, and some are worth keeping — reusing the pages Viva Topics left behind.
Where SecondBrain 365 fits
The first pages come from the work you are already doing
The plan above has one expensive step: copying answers out of email and meetings. That is the step SecondBrain 365 does. It is an agent with its own identity and company email inside your Microsoft 365, and it writes the wiki as pages on your SharePoint.
You describe the structure in a context file, in plain language — the same questions-as-sections you would draw up in week one. Then you bring it into the work: copy it on a thread, forward it a reply you have already written, invite it to a Teams meeting, add it to a Teams group or share a document with it. What is said there becomes pages, linked to each other.
It only writes from what it is shown, so the wiki grows with the team's real questions rather than a plan of what it should contain. You can require approval before anything is published, and every page stays editable by hand. More on what happens to an email once the agent is copied in, and on what a new colleague can read in their first week.
—One page per question people ask, titled the way they ask it.
—Keep how-to pages apart from policies.
—When a reply is forwarded, add it to the page it answers, with the date.
Plain language. Rewrite it whenever the work changes.
How do I…
- How do I get a new laptop?
- How do I connect to the VPN from home?
Policies
- Software you can install yourself
Known issues
- Meeting room screens — the workaround
—One page per supplier, with the contact and the contract dates.
—Keep who approves what in one page, linked to where it was decided.
—Record each change to the buying process as a dated decision.
Plain language. Rewrite it whenever the work changes.
Suppliers
- Office supplies — framework contract
- Cleaning services
Approvals
- Who approves what, by amount
Decisions
- New purchase request form — September
Three lines of rules instead of a page tree drawn in advance. The pages under each section are written from the replies, meetings and threads the agent was brought into.
FAQ
Questions about starting a company wiki
The answers to the questions one team is asked most often, in the words people use to ask them. Mission statements, org charts and welcome pages are easy to write and rarely searched. A first version that answers twenty real questions is worth more than one with a complete structure and nothing in it.
Shallow, and named in the reader's language. Three to five sections to begin with, page titles written as the question they answer, and links between pages instead of the same fact copied in two places. Add a section when enough pages need it, not in advance.
For each area, the team that does the work the pages describe, with one named person who decides where things go and which version is right. Not the person who installed the tool, and not a committee: ownership that is shared by everybody is exercised by nobody.
Ask them to write less. People already explain things in email, meetings and chat; the wiki fails when it asks for the same explanation a second time. Take the first pages from what they have written, credit them, and answer questions with links so contributing visibly saves them the next repeat.
Yes. In SharePoint in Microsoft 365 a wiki is a site made of modern pages, which are stored in the site's Site Pages library and can link to each other; site members with edit permission can add pages. If your company runs on Microsoft 365, you already have it. What SharePoint does not supply is the content.
No. It writes pages from the emails, meetings, Teams conversations and documents you bring it into, following the rules in your context file. What has never been said or written anywhere it can read stays in people's heads until someone puts it in writing. You can require approval before anything is published, and everything stays editable.