Most MSPs store procedures in the ticket that solved the problem, then never look at them again. The ticket gets resolved, the note gets buried, and the next time a similar issue comes in, a tech either remembers what to do or asks a colleague who remembers.
This is not a knowledge management strategy. It is a memory dependency, and it fails every time that colleague is unavailable, on vacation, or has left the company.
The three tools MSPs use instead of runbooks
In practice, MSP procedures live in one of three places: the PSA ticket history, a shared document folder, or a wiki or note-taking tool like Confluence or Notion. Each has the same problem: it was not built for how MSP work actually happens.
Ticket history is searchable but not browsable. You can find the resolution to a specific incident if you know approximately when it happened and what system was involved. You cannot browse a list of procedures for a client. There is no structure, no ownership, and no way to tell if the procedure in that ticket still applies to the current environment.
Shared folders are browsable but not searchable across clients. Every folder has a different naming convention. The most important document is usually the one that nobody updated last quarter.
Wikis and note tools are the best of the three, but they were built for internal company documentation, not for the multi-client structure of an MSP. A Confluence space built for 30 clients becomes a labyrinth within a year.
What a runbook tool actually needs to do
An MSP runbook tool has a specific shape. Procedures are organized by client first, then by system, then by type of issue. They are linked to the credentials they require and to the assets they describe. They have a version history that shows what changed, not just that something changed. And they are accessible from a ticket context, meaning a tech can open a relevant runbook from within an active incident without navigating away and losing context.
General-purpose tools do not do this. They are built for teams writing internal playbooks, not for service desks managing dozens of external environments.
The cost of the wrong tool
We tracked this with our pilot partners and found that the average tech spent 6.4 minutes per incident locating the right procedure or credential before they could begin the fix. That is the tax on using the wrong tool. Over a 40-incident week, that is over four hours per team of absorbed search time.
The less obvious cost is accuracy. When procedures are hard to find, techs remember approximate steps rather than following documented ones. The number of variations on how a task gets done grows over time, and so does the risk of an incident caused by the wrong variation.
What to do about it
Start by auditing where your procedures actually live today. Not where you intended them to live, but where they actually are. For most shops, the answer spans three to five different locations. The migration path is to move the procedures for your most active clients first, using a tool that enforces the client-first, system-level structure that makes lookups fast.
The goal is not a perfect knowledge base. The goal is a knowledge base that any tech on your team can use under pressure, without asking someone else for context. That bar is lower than most shops think, and it is achievable in a few focused weeks.