Confluence Team Wiki
A team wiki is the shared memory of a group. New joiners learn how work happens, veterans find answers without interrupting colleagues, and decisions survive staff changes. Confluence suits this job well, and a clear structure from day one decides whether the wiki thrives or turns into a junk drawer.
Start with a Purpose
Write one sentence that describes the wiki before you create a single page. A purpose such as "Everything the Support team needs to resolve customer issues" guides every later choice. When someone asks whether a page belongs, the purpose answers the question.
Plan the Structure
Create one space for the team. Build the page tree around the questions people ask, not around the org chart. Keep the first two levels simple.
SPACE: Support Team | +-- Home (welcome, quick links, latest news) | +-- How We Work | +-- Working Hours and Coverage | +-- Escalation Process | +-- Guides and Runbooks | +-- Refund Handling | +-- Account Recovery | +-- Meetings | +-- Weekly Sync Notes | +-- Archive
Build a Useful Home Page
The home page greets every visitor. Place a short welcome, a table of quick links, a blog posts macro for news, and a contact line for the wiki owner. A visitor should find the three most common destinations within five seconds.
Naming and Labelling Rules
Page Names
Choose titles that match the words people type into search. "Reset a Customer Password" beats "Password Process v2". Skip version numbers and dates in titles, since page history tracks those.
Labels
Agree on a short label list, such as runbook, policy, how-to, and onboarding. A shared list prevents near-duplicates such as howto, how-to, and guide.
Use Templates
Templates give every page of one type the same skeleton. A runbook template might include Purpose, Steps, Contacts, and Last Reviewed. Writers fill the sections in, and readers know where to look.
Assign Owners
Every page needs an owner. Add an owner line near the top, and mention the person who maintains the page. Pages without owners decay quietly.
| Role | Duty |
|---|---|
| Wiki owner | Guards structure, naming, and quality |
| Page owner | Keeps one page accurate |
| Contributor | Adds and improves content |
| Reader | Uses the wiki and leaves feedback |
Set Permissions
Most team wikis work best with open reading and controlled editing. Give the whole company view access when the content is not sensitive. Restrict individual pages only when the content demands it.
Create a Review Rhythm
- Review the top pages every quarter.
- Archive pages that no longer apply.
- Ask owners to confirm accuracy with a quick comment.
- Use analytics, where available, to spot unread pages.
Encourage Contributions
A wiki grows through small edits. Thank people who fix typos. Tell the team that imperfect pages are welcome, since a rough draft beats a missing page. Hold a short wiki session each month where everyone updates one page.
Common Failures
- Creating many top-level pages with no structure.
- Letting one person write everything.
- Skipping owners, which leaves outdated pages with no caretaker.
- Copying the same content onto several pages instead of linking.
A First-Month Plan
| Week | Goal |
|---|---|
| Week 1 | Create the space, home page, and top-level structure |
| Week 2 | Write the five most-asked how-to pages |
| Week 3 | Add templates, labels, and owners |
| Week 4 | Invite the team, collect feedback, and adjust |
Small, steady progress builds trust. A wiki that launches with ten excellent pages beats one that launches with a hundred half-finished pages.
Key Takeaways
- A clear purpose and simple structure anchor a team wiki.
- Naming rules, labels, and templates keep content consistent.
- Owners and review rhythms keep pages accurate.
- Small, frequent contributions beat rare large rewrites.