What Great MSP Documentation Actually Looks Like

Most MSPs judge their documentation by how much of it they have. Thousands of assets, hundreds of documents, and a password vault that took years to build all feel like evidence of a job well done, and volume is comfortable to measure because it only goes up. The trouble is that it tells you almost nothing about whether a technician can open a client record in the middle of a ticket and trust what they find.

When you ask service managers whether they audit their documentation on any regular interval, the most common answer is some version of "we should, but we don't." The reason usually has little to do with effort. Almost no MSP has a written definition of what great documentation is, so there is nothing to audit against, and "good enough" comes to mean the tech eventually found the password.

Great documentation does have a definable shape, and it is the same shape at every mature MSP that has taken the problem seriously. It comes down to six properties: completeness, freshness, accuracy, hygiene and linkage, standardization, and compliance. This article introduces them, and the four that follow take them apart one at a time.

Completeness

There is a specific set of records every managed client should have, and it is worth giving it a name: Minimum Viable Documentation. It covers the site itself, the network, identity and security, backup and recovery, the applications and vendors the business runs on, the people and places involved, and anything with an expiration date attached. The set is the same whether the client has ten seats or four hundred.

The word that matters in that sentence is populated. A record that was created during onboarding and never filled in tells the next technician the topic was handled, which is worse than having no record at all. The same standard applies to the MSP's own operations, where the internal runbooks and standards are usually a preview of the client records.

Freshness

Documentation begins decaying the moment it is written, and that has more to do with the nature of the work than with the technicians. Projects change five assets and leave the twelve documents that reference them untouched. Contacts leave the client and stay listed as the escalation point for years because nobody's job was to notice.

Current documentation is measured in dates. The typical record was touched in the last few months rather than the last few years, and credentials rotate on the schedule that was actually written down. Anything with an expiry attached, from certificates to warranties, is tracked closely enough that it never lapses by surprise.

Accuracy

Complete and current tell you whether a record exists and when it was last touched. Accuracy is about whether it still reflects reality. A populated field can be wrong, a device inventory can be a fraction of what the RMM sees because a sync broke two years ago, and a runbook can follow a structure nobody else on the team uses.

Accurate documentation is the kind a technician can act on without verifying it first. When the record and the environment disagree, the technician stops trusting the record, and once that happens the documentation platform becomes a place to store things rather than a place to find answers.

Hygiene

Two failure modes show up in nearly every tenant that has been around long enough. The first is clutter, most of it in the form of duplicates created because search failed and a technician wrote a new document instead of finding the old one. The second is disconnection, where the device does not link to its credential, the credential does not link to its owner, and the owner does not link to the site.

The two feed each other. A technician who cannot navigate from one record to the next falls back on search, and when search fails they create a duplicate, which makes the next search worse. Great documentation behaves more like a graph than a list.

Standardization

This is the property most MSPs never examine, because it can only be seen by looking across the whole client base at once. A single client record can look excellent while the tenant as a whole is running three different asset templates for the same service, each one inherited from a different acquisition or a different era of the business.

Consistency across clients is the difference between having documentation and running a documentation system. It is also the best predictor of whether the documentation will survive growth, because tribal habits that hold up at 20 clients rarely hold up at 100.

Compliance

The final property is the payoff for the other five. When a client under a security or compliance framework asks for evidence, great documentation already contains it, already current and already linked, with nothing assembled over a weekend.

Documentation that cannot do this usually failed the five properties above long before the request arrived. The auditor simply happens to be the first person who noticed.

How Lexful fits in

Every property above can be maintained by hand, and almost nobody manages it, because doing so takes a dedicated documentation team most MSPs will never staff. We built Lexful around a different division of labor. Lex, the AI built into the platform, reads every record in the tenant, checks it against a defined standard, and drafts the fixes. A technician reviews and approves them. Each article in this series closes with the specific mechanics that apply to that property.

Where this series goes next

The next four articles take the six properties in order:

Most owners can already name the client whose documentation would embarrass them in front of an auditor. What they usually lack is a clear definition of what good would be, and a way to get there that does not cost a technician their weekend.