Your Best Documentation Isn't Where Your Techs Are Looking

Most MSPs have decent documentation somewhere. The problem is “somewhere” is often not where techs are actually working when they need it. SOPs and KBs end up scattered across SharePoint, an internal wiki, or a folder structure that made sense to whoever set it up years ago, while techs live inside the PSA all day.

A documented gap that’s more common than it looks

One 100-technician MSP we spoke with runs a highly proactive, face-to-face service model with named technicians per client, exactly the kind of shop you’d expect to have tight documentation discipline. And they do, it just lives in SharePoint rather than their documentation tool. The knowledge exists. It’s just structurally disconnected from the ticket workflow where a tech would actually go looking for it mid-resolution.

Why this gap persists

Nobody sets out to build documentation in the wrong place. It usually happens because SharePoint (or an internal wiki) predates the current documentation tool, or because certain teams standardized on one platform for internal collaboration and never migrated. Once a few hundred SOPs accumulate somewhere, moving them becomes its own project that never quite gets prioritized.

The cost isn’t obvious day to day. Techs either know where to look because they’ve been there long enough, or they solve the problem from scratch and don’t bother updating the “official” doc afterward because it’s a hassle to get to. Either way, the documentation slowly drifts out of sync with how work actually gets done.

Connecting the dots without a full migration

The fix doesn’t have to mean migrating years of SOPs into a new system. It’s often more realistic to connect the existing documentation source, whether that’s a specific SharePoint site, a Hudu instance, or an IT Glue account, directly into the ticket workflow, so relevant docs surface automatically based on what the ticket is actually about, not just keyword matches on the title.

That last part matters more than it sounds. Ticket titles are often vague or inconsistent, so a system that indexes the actual content of your documentation, not just filenames, is what makes this connection useful rather than just another search box nobody uses.

What good documentation matching looks like

Once documentation is properly connected to the ticket flow, techs get the right SOP or past resolution surfaced automatically, with a link back to the exact source article. That link back matters too, since techs want to verify where a suggestion came from before they trust it, especially for anything client-specific.

If your team’s best documentation lives somewhere your techs don’t naturally look, that’s worth fixing before it turns into repeated troubleshooting on issues you’ve already solved. If you’re wrestling with this, happy to talk through how other MSPs are tackling it. Check out Mizo to see how documentation gets connected into the ticket workflow.