.webp)
Why Your Best Tech Is Your Biggest Risk (And What to Do About It)
Most MSPs never write down what their techs know. Industry conversations put the number at 85% or higher, and the MSPs who hear that stat usually laugh, then admit it's probably worse at their shop. That gap is the single biggest operational risk most MSPs are carrying and not tracking. This post breaks down why it happens, why "just document more" doesn't fix it, and what actually works.
Why don't MSPs document what their techs know?
It's not laziness and it's not spite. It's incentive gravity: if you're the only one who knows how to fix something, you're safe. The moment you document it, you've made yourself replaceable. Nobody says this out loud, but every tech feels it.
One senior tech — six or seven years in the field, four different MSPs — was asked how much of what he knew was ever written down. His answer: about 10%. That's a guy who's a massive asset to his company every single day he shows up. The day he leaves, all of it becomes a liability, because it walks out the door with him.
This isn't a training problem. It's a design problem. MSPs have built workflows where documentation is optional, happens after the fact if it happens at all, and depends entirely on a tech remembering to do it — and wanting to.
What's the real cost of undocumented MSP knowledge?
The cost shows up as slower onboarding, repeated tickets, and a business that can't survive one resignation without pain. If your best tech got hit by a bus tomorrow, or just called in sick for a week, would your clients notice in hours or days? For most MSPs, the honest answer is hours.
That's not a hypothetical risk. It's a math problem. Every unwritten fix is a fix your team will re-solve from scratch the next time it comes up, probably by interrupting the one person who already knows the answer.
Why doesn't "just document more" work?
Because it's a policy fix for a friction problem. Telling techs to document better doesn't change the fact that documenting takes time, breaks flow, and competes with the next ticket in the queue. Policies get ignored under deadline pressure. Every time.
The fix that actually works is removing the friction, not adding a rule. Capture the knowledge automatically at the point of the ticket — while the fix is fresh and the tech is already typing the resolution — instead of asking someone to reconstruct it from memory at the end of the week. If it's not automatic, it's not going to happen consistently, no matter how good the intentions are.
What's the new definition of "done" for a support ticket?
A ticket isn't done when the fix works. It's done when it's documented. That single redefinition changes everything downstream — onboarding speed, ticket reuse, how exposed you are when someone leaves.
Most MSPs are shipping half-finished tickets every day and calling it good, because nobody ever updated what "done" means for the AI era. The old bar was "the client's problem is fixed." The new bar has to include "and the next person who hits this doesn't have to solve it from scratch."
Where does AI actually help with MSP knowledge management?
AI's job here isn't replacing your senior tech. It's getting them out of what shows up as "default search engine syndrome" — the constant shoulder taps and Slack DMs that turn a five-minute question into twenty minutes of someone's day, every day, for years.
Done right, AI captures the work as it happens, surfaces the pattern across tickets, and hands a new hire the answer directly — without the veteran tech ever having to stop and explain it in person. The senior tech's expertise scales past their own inbox instead of being gated behind it.
This is the whole idea behind HelpGhost: capture knowledge automatically from every resolved ticket, and surface it back to the team without anyone having to remember to write it down. Your team's knowledge doesn't disappear. See how it works →
5 things to try at your MSP this week
- Redefine "done." Does your ticket-closing process include documentation, or does the ticket just need to technically work?
- Ask your best tech, honestly, how much of what they know is actually written down anywhere.
- Find your point of capture. Where could documentation happen the moment a ticket closes, instead of relying on memory later?
- Have the real conversation with your hero tech about getting what's in their head into the org — without it feeling like they're documenting themselves out of a job.
- Track the shoulder-tap tax. Pick one senior person and count how many interruptions they field this week just answering questions only they know.
FAQ
What percentage of MSP technician knowledge goes undocumented?
Industry conversations consistently land on 85% or higher — a figure most MSP owners agree with once they think about their own team.
Why do MSP technicians avoid documenting their work?
Not out of spite. Being the only person who knows a fix creates job security, so documenting it can feel like giving that up. The fix is removing the friction to document, not asking techs to change their motivation.
How can MSPs capture technician knowledge without adding extra work?
Capture it automatically at the point the ticket is resolved, rather than relying on techs to write it up later from memory. Friction removal beats policy every time.
What should "done" mean for an MSP support ticket?
A ticket is done when the fix works and it's documented. Fixed-but-undocumented is half a ticket, and it's the version most MSPs are shipping today.
This post is based on a conversation between Jamie Cain, CEO of HelpGhost, and John Harden of Lemhi and Coffee Chats. Watch the full episode →