What Every Client Record Needs Before It Counts as Documented

A technician picks up a ticket for a client they have never worked before, opens the client record, and finds a backup asset sitting right where it should be. The vendor field is filled in and everything else is blank. There is no target, no schedule, no retention setting, and no restore procedure, so the technician does what technicians always do in that situation and messages the person who onboarded the client three years ago.

That backup asset counts as documentation in every report the MSP runs. It exists, it has a name, and it sits under the right client, which is exactly the problem. The first article in this series named six properties of great documentation and put completeness at the top of the list. This one spells out what Minimum Viable Documentation contains, what populated means for each part of it, and the simple rule that catches most of the gaps before a technician finds them the hard way.

The three states every record can be in

Any record in a documentation platform is in one of three states, and only one of them is useful.

The first state is populated and current, where the fields contain real information that matches what is deployed today. The second is present but hollow, where the record was created and never filled in, or was filled in once and abandoned. The third is absent, where nobody ever created the record at all.

Most MSPs treat the second and third states as different problems, with hollow records counted as partial progress and absent records counted as the real gap. In practice the hollow record is the more expensive of the two. An absent record tells a technician that the information is not there, and they go find it. A hollow record tells them the topic was handled, so they trust it until the moment it fails them, and by then they are usually on the phone with the client.

When technical alignment teams start owning documentation, the first thing they tend to discover is how much of the tenant is in that second state. Records got created during onboarding because the template asked for them, the fields that were easy to fill got filled, and the rest waited for a follow-up that never came.

Minimum Viable Documentation: the baseline every client should carry

Every managed client, whatever its size, should carry the same set of records. That set is the Minimum Viable Documentation, and next to each item below is the definition of populated, because the definition is where most of the hollow records hide:

None of this is exotic. The difference at MSPs with great documentation is that these definitions are written down, so a record is either populated to the standard or it is flagged, and the answer does not depend on which technician did the onboarding.

How to find gaps before a technician does

The most useful habit an MSP can build around completeness is a simple conditional check. If a client has this, they should also have that. If the record on the right side of the condition is missing or hollow, you have found a gap.

The pairings write themselves once you start looking:

Most MSPs already do a version of this in their heads. The problem is that the check lives in the head of whoever is running the review that quarter, so the results depend entirely on what that person knows to look for. A team member who has never worked a Meraki environment will not think to check for the renewal that keeps the hardware working. A technician who came up in the cloud will not think to look for the on-premises backup that still protects the file server. Writing the pairings down, and checking them the same way every time, is what turns a shotgun review into a standard.

The MSP's own baseline

The internal side gets less attention because no client ever asks to see it, and it deserves the same definitions.

An MSP that takes completeness seriously holds populated records on itself: client onboarding and offboarding runbooks, new-technician onboarding, and the major-incident runbook. It also documents its own identity and backup configuration, its security standards including the password policy, a vendor and distributor list, a licensing register, and a naming convention. Two of those matter more than the rest for this property. When a team says they are using every feature the platform offers and their client records still come up hollow, the missing piece is almost always the naming convention or the client onboarding runbook. Those are the two documents that would have told the technician which records to create and which fields were required.

If the onboarding runbook does not specify which records get created and which fields get filled before a client is considered live, the platform will fill up with scaffolding no matter how good the tooling is.

How Lexful gets you there

Populating the baseline for every client by hand means someone opening every record, checking every field, and chasing the client for what is missing. Lexful is built to do the opening, checking, and drafting itself, and to hand a technician the result to approve.

Where this series goes next

Completeness is the property that makes the others possible, because you cannot keep a record current, accurate, or linked if it was never populated in the first place. The next article covers the second property, freshness: what it takes for documentation to stay current once it has been populated, how to read the age of a tenant, and how to build review dates into the platform so freshness stops depending on a quarterly cleanup nobody has time for.

A useful first step this week is to pick one client, open each record in the Minimum Viable Documentation list above, and mark it populated, hollow, or absent against the definitions. The result is usually enough to settle the question of whether the platform is full of documentation or full of scaffolding.