Wiki Software for IT Teams and MSPs: Runbooks and SOPs That Stay Current
A guide to how MSPs and IT teams organise runbooks and SOPs in a wiki, and how to keep documentation current
TL;DR
- Runbooks and SOPs are different documents with different lifespans, and filing them together is the fastest way to get your technicians to stop trusting the wiki.
- For MSPs, structure matters more than features. Client separation, consistent naming, and search that matches how a technician looks things up will carry you further than a long feature list.
- Your documentation platform describes how to reach every client you serve, which makes it a security asset and not only an efficiency one.
- A wiki is the right home for procedures and institutional knowledge. It isn't a password vault, an asset database, or a replacement for your RMM.
It's 10:40 in the morning and a technician is on their third client of the day. The VPN at this one was reconfigured about eight months ago by someone who has since left the company. The change is documented somewhere. Probably in a closed ticket. Possibly in a Slack thread. There's also a Word file on a shared drive that might have it, though nobody's opened that folder since last year.
Twenty minutes go by before any real work starts.
Most managed service providers don't have a documentation problem in the sense of nothing being written down. Plenty gets written down. The problem is that it can't be found quickly, and when it is found, nobody's confident it's still accurate. The difference between documented and usable is what eats into valuable company time.
This post covers what to document, how to structure it so people use it, and how to keep it current once it exists.
What MSP documentation actually covers
Before you can structure anything, it's important to know exactly what you're storing, because these documents all have different functions and should be stored differently.
The first two rows look similar from a distance, and that resemblance causes most of the trouble.
An SOP and a runbook both tell someone how to do something, so they end up filed together, reviewed together, and eventually ignored together.
The next section breaks down exactly how they differ and why keeping them apart matters.
Why this matters more for MSPs than for internal IT teams
An internal IT team works inside one environment. They know it well, they see it every day, and when something isn't written down clearly, they can usually just ask a teammate who was there when it was set up.
An MSP doesn't have that luxury. A technician might work across four unrelated client environments in a single shift, and every one of them names things differently, still runs some older hardware, and has a reason why a particular server can't be rebooted on a Tuesday.
Nobody remembers all of that across dozens of clients, so anything unclear in the documentation turns into a phone call, a delay, or a mistake.
Runbooks and SOPs are not the same document
An SOP describes a process: what happens, in what order, who's accountable, and what has to be recorded. A runbook describes an execution: the specific commands, screens, and steps for one system in one environment, right now.
A quick test for which one you're writing
- Somebody is doing a task and needs to know the next step. That's a runbook.
- Somebody asks what governs this process and who signed off on it. That's an SOP.
- Plenty of processes need both. Password rotation needs an SOP saying who approves what and what gets logged, plus a runbook per client showing exactly where the rotation happens in their environment.
Keeping these separate is very important, because an SOP written six months ago is probably still accurate, while a runbook written six months ago might describe a firewall that got replaced in March.
When both sit in the same folder with the same review cycle, technicians start treating everything with the same suspicion, and the SOPs get ignored alongside the runbooks that are no longer accurate.
Structuring a wiki for multi-client work
This is where most documentation systems either work or quietly fall apart.
- Spaces: one per client, plus a global space
The split works because a technician sent to one client should see everything about that client and nothing about the others, while the rules your company follows everywhere should live in one place you can update once instead of forty times.
A space for each client, holding anything that only makes sense for their setup:
- Runbooks for their systems
- Network notes and diagrams
- The specific things about their environment nobody would guess, like the server that can't be rebooted on a Tuesday
One global space, holding everything that applies no matter whose office you're in:
- SOPs
- Escalation paths and who to call out of hours
- Security incident procedures
- The onboarding material every new technician reads in their first week
Set permissions at the space level rather than page by page. Page-level permissions look flexible at the start and become impossible to audit once you're past a few hundred pages.
Client spaces are usually internal to your team, though some MSPs open them up read-only so clients can see their own documentation. That's a decision to make per client, and it's easier to make before you start writing than after.
If you're building that global space from nothing, our guide on setting up a company policies wiki from scratch walks through the same process for the policy side of it.
- Naming pages the same way every time
Pick a pattern and write it down in the global space:
- ClientName-Runbook-Subject for client documentation
- Global-SOP-Subject for company-wide procedures
Decide the small things once, because inconsistency is what breaks search. Do you abbreviate client names or spell them out? Are dates written one way across the whole system? Is it "M365" or "Microsoft 365" everywhere?
The answers to these don't matter much if the documents can't be found, so pick one version and stick with it. A naming pattern nobody can remember works the same as having none at all.
- Tag for the way people search
Add three to six tags per document covering platform, task type, and technology.
Once a client space passes a few dozen pages, browsing through it stops being practical and people start searching instead. Tags are what let someone narrow that search down to the exact page they need.
- Organize around how technicians look things up
Most technicians search client first, then issue type. If your structure follows that same path, people find things on the first try. But if it's built around your company's departments, or around a filing system someone designed in a planning meeting, they don't.
Watch how your team searches for a week before you commit to a structure. The pattern is usually obvious once you look for it.
Keeping documentation current
Documentation usually goes out of date because of how the system was set up in the first place, which means the setup is where you fix it.
Every runbook needs a named owner
Not a team. A person. Documentation that belongs to everyone belongs to nobody, and shared ownership is how a runbook sits untouched for two years while four people each assume someone else is watching it.
When a technician changes hands on a client, the runbook ownership moves with the account.
Update the runbook when you make the change
Quarterly reviews do catch outdated documentation, but they catch it late. Something that changed in January doesn't get noticed until April, usually by a technician who's already lost an hour working from instructions that were wrong.
A better approach is to update the documentation as part of the change itself. If a ticket changes something in a client's environment, updating the runbook becomes one of the steps you complete before closing that ticket. The quarterly review is then only there to catch what slipped through, rather than being the thing you rely on.
Write the failure states
A runbook that only covers what happens when everything goes right leaves the reader stuck at the exact moment they need help. For each step, cover what happens if errors occur, who to escalate to, and what "finished" looks like.
Ask yourself while writing: if the portal is down, does this document tell the reader what to do next?
Use version history to track changes
Version history answers who changed what and when. That's useful during an incident review, and it's useful again when a client asks how you manage changes to their environment. Choose a platform that records this automatically and you get the record without anyone having to maintain one.
Your documentation is part of your attack surface
An MSP holds privileged access to a lot of organisations at once. That makes the MSP itself a more efficient target than any single client, because breaching one provider can open the door to dozens of businesses. And the documentation system is where that access is described in detail: how the networks are laid out, where the sensitive systems sit, and which accounts have what permissions.
This isn't a hypothetical concern. In April 2022, cybersecurity authorities from the US, UK, Australia, Canada, and New Zealand published a joint advisory on threats to managed service providers, warning that state-sponsored actors were increasingly targeting MSPs specifically to take advantage of the trust relationship between provider and customer. The advisory sets out actions for both sides, and many of its recommendations line up with NIST 800-171 and CMMC controls.
If you're already working through those controls for other reasons, your documentation platform belongs in that scope alongside everything else. We looked at the same question from the government contracting side in why on-premises wikis matter for FedRAMP-ready documentation.
What that means for where your documentation lives
Self-hosting is one answer, and here's what it involves in full rather than only the parts that sound good:
- Your data never leaves infrastructure you control.
- You define your own compliance posture, including access controls, encryption, and retention, instead of inheriting whatever your vendor has decided.
- Hosting, backups, upgrades, and security patching become your team's responsibility.
That third point is real work. For an MSP it's usually work your team already does for clients, so it may cost you less than it would another business, but it still has to be done by someone.
When a client's data residency requirements become yours
If one of your clients is contractually or legally required to keep their records inside a particular country, that requirement passes to you the moment you start holding documentation about their environment.
Some documentation tools only run in the cloud, on servers the vendor owns, in whichever countries the vendor has chosen.
If your client's rules say their information has to stay in a specific country and the vendor doesn't have servers there, no setting inside the tool will fix that. Running the software on your own servers is the only way to guarantee where the data sits.
What a wiki does well, and what it doesn't
Documentation tools get compared as though they're interchangeable. They aren't, and being clear about the boundaries saves you from buying the wrong thing.
A wiki is the procedures layer. It's where the writing lives: the runbooks, the SOPs, the reasoning behind decisions, the context that never fits in a ticket. It sits alongside a credential manager and whatever your RMM already collects rather than replacing either of them.
Vendors in the MSP tooling space describe open-source wikis this way themselves, and they're right to. If you need password vaulting and automated asset collection in one system, a wiki won't get you there. If what you need is somewhere to write things down that people can find and trust, it's a strong fit, and it's the piece most MSPs are weakest on.
If you're comparing options at that layer, we've reviewed several of them in our guide to the best open source knowledge base software.
How Docmost works as a wiki for MSPs and IT teams
Docmost is an open-source wiki and documentation platform you can run on your own infrastructure.
For multi-client work, the pieces that matter are:
- Spaces with their own permissions, so each client's documentation is separated and access is managed at the space level. These are spaces rather than fully isolated tenants, so plan your structure with that in mind.
- Page history, so you can see who changed what and when without needing a separate audit process.
- Search across spaces, so a technician who knows the client and the symptom can find the runbook without knowing where it was filed.
- Self-hosted deployment, so client documentation stays on infrastructure you control and inside whatever jurisdiction your contracts require.
Frequently asked questions
- Can I give a client read-only access to their own documentation?
Yes, and some MSPs offer it as a perk. Set the permission at the space level, and keep anything internal, like your commercial notes or escalation contacts, in a space the client can't reach. Decide that boundary before you share, because you can't unshare something a client has already read.
- How do we move existing documentation across without losing the structure?
Decide the structure you want first rather than copying what you have, since most MSPs are leaving a system that was already causing problems. Move the global SOPs first, because they apply to everyone and get you working quickly. Then go client by client, deleting anything out of date as you go.
- What happens to our documentation during an outage?
The documentation you need most in an incident is often about the system that's down. Keep a small set of critical procedures available separately, whether that's an exported copy, a second instance, or a printed escalation sheet. If you self-host, don't put the wiki on the same infrastructure it tells you how to recover.
- How do we get technicians to actually use the wiki once it's built?
Adoption follows trust. If search returns the right page and the page turns out to be correct, people come back. If it doesn't, they go back to asking a colleague. Make updating documentation a step in closing a ticket rather than a separate task nobody has time for.
- Will this documentation hold up in a client compliance audit?
Usually, if the basics are in place. Auditors want to see that procedures exist, that people follow them, and that changes are traceable. Page history covers the last one, and named owners with review dates cover the rest. Findings tend to come from procedures nobody has followed in a year, not from the platform they're stored in.
Give your technicians documentation they can find and trust
If your MSP documentation is currently spread across tickets, shared drives, and people's memories, don't try to fix all of it at once.
Pick one client, build their space properly, and write the global SOPs your team already relies on. You'll learn more about the structure you need from doing one client well than from planning the whole system in advance.
Start a free trial or talk to our team about running Docmost on your own infrastructure.
