One of the very first videos I ever made was about documentation and standardization. That was over two years ago, and I’m long overdue for a rehash. The core fundamentals haven’t changed, but the tools available to you have, and that’s worth talking through.

Why Documentation Still Matters

If you run an MSP, good documentation is the difference between a business that scales and one that runs on tribal knowledge trapped in a few people’s heads. This cuts both ways. Internal documentation covers your processes and procedures, your HR basics, and the expectations your team operates under. At my former MSP, we had a clear policy that techs couldn’t remote into a user’s machine without talking to that user first, unless the client had given us pre-authorization to jump in anytime. That kind of thing needs to be written down somewhere everyone can find it. That sort of thing also needs to live in your new employee onboarding and training.

Client-facing documentation matters just as much, and it’s where most of the real value lives. That’s what we’re really talking about today.

What Good Documentation Actually Looks Like

The most important rule I can give you is this: pick one place for your documentation and stay there. The moment you have a second place, you add confusion to the mix. I’ve never seen smart techs get so dumb as when there are two systems to check. They’ll check one. They won’t check both. It’s frustrating when you’re trying to solve a client issue and the information exists somewhere, just not where anyone looked.

The second piece is understanding what it means for your client to be up. Not server status. Not a green light on a dashboard. It’s whether they can actually function and make money. I had a client years ago who used multiple label printers to ship UPS packages all day long. If those printers went down, it cost them real money and created real delays. I had other clients with a label printer they used twice a year, and if that one broke, nobody cared if it sat broken for a week. Same equipment, same failure, completely different stakes depending on who you’re talking about. Your documentation should reflect that difference, and your client dashboard, whether that’s Hudu, IT Glue, SharePoint, or whatever you use, should make it obvious at a glance what being up actually means for that specific client.

Everything else (the one-off items and nuances) still need to be logged. It’s just not the priority during onboarding. Nail down what up means and your core network infrastructure first. The rest gets caught over time. That only works if your team has a culture of continual improvement, where a tech who learns something new about a client actually logs it. The same logic applies to projects. If a project changes what’s going on with a client, the documentation needs to reflect that as part of finishing the project, not as an afterthought three weeks later.

One exception worth calling out: passwords. I’m fine keeping passwords in a separate tool from your general documentation. Most dedicated password managers have stronger security than the password features built into documentation platforms, and that separation isn’t a bad thing. Pick a direction here and stay with it.

How AI Changes the Equation

AI has entered the chat. . . Here’s the big update since my last video on this topic. Tools like Claude, ChatGPT, and Copilot can now connect directly to your documentation platform through something called an MCP connection, which is essentially a bridge that lets an AI tool actually read and write to your documentation instead of just chatting with you about it in a separate window.

Once that connection exists, you can talk through a process out loud, or type a quick description, and let the AI tool turn it into documentation for you. I can talk a lot faster than I can type, and that’s true for most people. For a tech who dreads sitting down to write up a process step by step, dictating it and letting AI structure the writeup removes a huge amount of friction. That friction is usually the actual reason documentation doesn’t get written, not a lack of knowledge, just a lack of patience for typing it all out.

I’ll mention that this same MCP connection can help your team search and retrieve documentation faster too, which is a real benefit if you’ve ever dealt with a clunky internal search that returns nothing useful. But that’s a secondary win. The angle I care about most is lowering the barrier to creating documentation in the first place.

None of this works without a human checking the output. If a tech dictates a process to an AI tool, that tech must verify the documentation is accurate before anyone else relies on it. This isn’t fire and forget. It’s also worth teaching your AI tools, and your team, that saying “I don’t know, go check” is a better outcome than a confident answer that’s wrong. That matters even more when techs start using AI to search existing documentation instead of just creating it.

Culture Comes First

AI is an accelerant here, not the fix. The real goal is building a culture where documentation happens as a matter of course. That means updating a doc the moment something changes, creating documentation at onboarding, and treating documentation as a required step when a project wraps up, not something you get to eventually. The last thing you want to do is build up “documentation debt.” Most of your clients have enough technical debt that needs to be paid back. Don’t create more problems for your future self.

If your documentation tool is clunky, that’s not a reason to skip writing things down. Raise your hand and say something. If everyone agrees the tool is the problem, go find a new one, and when you do, put an MCP connection on your list of requirements so your team can take advantage of AI from day one.

Documentation is easy to get wrong and genuinely valuable to get right. Build the culture first, let AI lower the friction, and you’ll end up with a system your whole team actually trusts.