Why MSP Documentation Goes Stale the Moment It's Written
MSP documentation goes stale because nothing in the workflow is responsible for keeping it true. Audits can't outrun the rate of change, homemade AI layers age out in months, and once techs lose faith they stop reading and writing into the platform. Here's how Lexful engineers freshness into the substrate itself.
Plenty of MSP owners have tried to fix the documentation problem by hand. The ambitious ones have gone further than that. Some have even built their own AI layer on top of IT Glue or Hudu: export the documents, sanitize them with a script, drop them into a vector database, wire up a chatbot, and let the team ask questions in plain English. The build takes a long weekend. It works, for a while.
Then the same thing happens every time. The export was a one-time job; the refresh isn't. Manually re-exporting thousands of documents every week, sanitizing them, and re-indexing them isn't a maintenance task anyone wants to own. So the homemade AI documentation layer goes stale inside six months, ages out of usefulness inside a year, and the operator who built it admits, when pressed, that the project isn't sustainable. They built the right product on the wrong substrate. The substrate underneath was always going to win.
That's the freshness problem in a nutshell. The documentation set isn't bad because the team is sloppy or because the tool is wrong. It's bad because nothing in the workflow is responsible for keeping it true. A doc gets written, the underlying environment changes, and the doc doesn't change with it. Multiply that by ten thousand assets and three years, and you get what most MSPs have on their hands today: a knowledge base nobody trusts.
Why discipline isn't the problem
An MSP with 70,000 assets in IT Glue isn't an edge case anymore. It's roughly the asset count a well-established MSP reaches by year five or six, and at that scale a full audit takes about six months, by which point a meaningful share of what got audited is already wrong again. The platform never catches up to itself, because the audit can't outrun the rate at which the environment is changing.
In my opinion, this is the part the industry has been getting wrong for a decade. Documentation platforms were built to store what a human typed. They were not built to know whether what got typed was still true. The maintenance burden lands on whichever technician happens to be on a related ticket, if they remember, if they have time, and if they can find the doc again. At a few hundred documents per client, this (barely) survives. At seventy thousand, it does not.
The architecture is the deeper issue, because the platform itself has no signal that anything has drifted. There's no field that says "this runbook references a firewall the client replaced last spring." There's no daily check against the current PSA. There's no version of the document that regenerates from live source data, so the doc and the reality drift apart silently. Nobody notices until a tech opens the runbook in the middle of an incident and finds the password is wrong.
The cost of stale documentation
The costs of stale documentation are different from the costs of broken search. Search costs you a few minutes per ticket. Staleness costs you outcomes, in places that hurt:
Once the team has lost faith, the documentation becomes write-only. Techs stop reading it. They stop writing into it, because they can see nobody else reads it either. The senior team becomes the source of truth, which sounds fine until that senior team tries to take a vacation, or leave the company, or scale to the next tier of client volume. Tribal knowledge is fragile by design.
How Lexful actually keeps docs fresh
We built three mechanics into Lexful that exist specifically to fight decay. None of them depend on a technician remembering to update something.
These three mechanics compose into a fourth thing, which is daily audits run by Lex agents. The agent walks the corpus, flags drift against the framework, surfaces the deltas, and queues edits for the technician to approve. Minor edits get applied automatically with revision history, so a rollback is always one click away. Major edits route through human approval. The audit is no longer a project anyone schedules and instead becomes a continuous reading the platform produces on its own.
The impact of real-time documentation
In addition to reducing time to ticket resolution, with documentation you can trust, several recurring things stop feeling urgent. Compliance prep stops being a fire drill, because the framework was being graded all year. The QBR you're walking into Friday has a network diagram that was regenerated yesterday from the client's actual environment. A new tech onboarding next month inherits a documentation set that's already true, instead of them spending their first quarter sanity-checking.
The cleanup itself stops being a project. The first move most operators make on day one with Lexful is to point Lex at the migrated set, ask for the most stale and most poorly documented assets, and walk through suggested edits in bulk. The work that was six months of human time becomes fifteen minutes of approving Lex's queue. The most-delayed projects often become the first thing the team does in week one.
What needs to change
If your last full audit was eighteen months ago, or if your senior techs keep the real source of truth somewhere outside the documentation platform because the platform isn't trustworthy anymore, the platform isn't the only thing that needs to change. The maintenance model underneath it does. Documentation that stays fresh isn't a discipline problem you can solve with another team meeting. It's an engineering problem, and we built Lexful to solve it.