An internal wiki: keeping your team's knowledge in one place

Ask a small membership team where to find the refund rules and you'll often get three answers: a shared document, an old email thread and “just ask the owner.” Knowledge collects wherever it was first written down, in chat messages, personal notes, file folders and someone's memory. Every time a question comes up, someone spends ten minutes hunting or interrupts the one person who knows.

An internal wiki is a single, searchable set of linked pages where your team keeps everything it needs to run the membership. It isn't for members; it's for you, your helpers and anyone who joins later. Done well, it cuts interruptions, speeds up onboarding and keeps the business running when someone is away. Any tool that lets you create linked, searchable pages with editing permissions will do, from a dedicated wiki tool to a well-organized shared document space.

What belongs in the wiki

A wiki becomes useful when it holds the answers people actually look for. For a membership team, that usually means:

• Procedures: step-by-step instructions for routine tasks. If you've started writing down how your membership runs, those procedures become the core of the wiki.
• Policies: refunds, cancellations, pauses, moderation rules and what support can approve.
• Product facts: plans, prices, what each level includes, current offers and any legacy plans still running.
• Replies and tone: the saved reply library, or a link to it, plus a note on how you sound.
• People and contacts: who owns what, working hours, and outside contacts such as the accountant or developer.
• Tools: each tool's job, who has access and where its how-to pages live.
• Decisions: a log of significant decisions and the reasons behind them.

What doesn't belong: passwords and secret keys, which should live in a password manager, and personal member data, which should stay in your membership platform. Link to where things live rather than copying them.

Structure it the way people ask questions

Organize the wiki around the questions your team asks, not around job titles. Here's the home page used by Wendell, a hypothetical owner who runs a membership for small-farm vegetable growers with two part-time assistants:

Start here: how the membership works on one page, who does what, how we communicate.

Helping members: support procedures, saved replies, refund and pause policies, escalation rules.

Publishing: the monthly growing guides, the video workflow, the newsletter checklist.

Community: guidelines, moderation steps, weekly prompts.

Money and admin: the monthly bookkeeping routine, tool register, supplier contacts.

Decisions log: what we decided, when and why.

Keep the top level to about six sections. Deep nesting makes pages hard to find; good titles and search do most of the work.

Use a simple page template

Consistent pages are easier to read and easier to keep current. Give every page the same few elements:

1. A title that says what the page answers, such as “Refund an annual plan” rather than “Refunds info.”
2. An owner: the person responsible for keeping it accurate.
3. A last-reviewed date.
4. The content itself, as short as it can be.
5. Links to related pages.

The decisions log deserves its own simple format. One of Wendell's entries looks like this:

Decision: stop refunding monthly renewals; offer a pause instead.

Why: most monthly refund requests came from members who wanted a break during their busiest weeks on the farm, and a pause kept more of them.

Who decided: Wendell, after discussion with both assistants.

What changed: the refund policy page, two saved replies and the cancellation page wording.

Months later, when someone asks why monthly refunds stopped, the answer takes seconds to find.

Make it the first place people look

A wiki only works if the team uses it. A few habits make that happen:

• Answer with a link. When someone asks a question the wiki covers, reply with the link rather than the answer. If the wiki doesn't cover it, answer, then add the page.
• Update at the moment of change. Edit the page when a process or policy changes, before announcing the change.
• Onboard through it. A new helper's first day should start on the “Start here” page.
• Keep it in the weekly rhythm. A standing question in your team check-in, “anything that should be in the wiki?”, catches knowledge before it vanishes into chat.

For a team spread across locations, the wiki becomes the shared memory that holds everyone together, which is why it pairs naturally with the practices in managing a small remote team.

Keep it current and permissioned

An out-of-date wiki is worse than none, because people stop trusting it. Every quarter, list the pages that haven't been reviewed for six months and ask their owners to confirm or update them. Archive pages for things you no longer do. Let everyone suggest edits, but limit who can change policies, and remove access for anyone who leaves on the day they go.

A current wiki also forms the backbone of a continuity plan: if you were suddenly unavailable, someone could keep the membership running from what's written there.

Your first steps

1. Choose one place for the wiki and set up no more than six top-level sections.
2. Move your existing procedures and policies into it, adding an owner and review date to each.
3. Write a one-page “Start here” overview.
4. Start a decisions log with the last three significant decisions you made.
5. Adopt the answer-with-a-link habit with your team for a month.
6. Schedule a quarterly review of stale pages.