The page that was right two years ago
An engineer picks up a ticket for a client they have never worked on. They open the documentation: network diagram, server list, the line-of-business application's support contact, the Wi-Fi setup, the process for adding a user to the finance system. The server list has a machine that was retired last year. The support contact has left the vendor. The finance system process refers to a menu that no longer exists.
So the engineer asks in the team chat, and the one person who knows this client answers when they are free. The documentation tool the MSP pays for is used as a password vault and little else.
Why documentation decays
Documentation is written once, at onboarding, when there is time and a reason. After that, every change to the client's estate is made through tickets, and updating the documentation is an optional extra step at the end.
- Factual details (devices, IP addresses, licences) change constantly.
- Procedures go out of date when an application is upgraded.
- Engineers update the ticket but not the documentation.
- There is no indication of which pages are stale.
- Nobody owns documentation quality for each client.
What stale documentation costs
| Stale item | Effect |
|---|---|
| Wrong device list | Engineers work on the wrong machine or miss one |
| Old procedure | Tasks done wrongly, then redone |
| Wrong vendor contact | Delays when escalating a problem |
| Knowledge in one person's head | Service stalls when they are away |
| Distrust of the docs | The documentation tool becomes shelfware |
Documentation that keeps itself honest
- Automatic sync of factual sections from your tools: devices and specifications from the RMM, users and licences from Microsoft 365, network devices and addresses from your network management tools, into IT Glue, Hudu or your documentation tool.
- Review dates on procedure pages, with an owner per client, and a list of pages overdue for review.
- Links between procedures and the systems they relate to, so when a system changes (new version, replaced server), the linked procedures are flagged for review.
- A prompt when an engineer closes a ticket that changed something documented, offering the related page to update.
- Optional AI-drafted updates from ticket notes, using a model such as Anthropic Claude, which an engineer reviews and approves before the page changes.
- A documentation health score per client, used in internal reviews, not shown to the client unless you choose.
After: engineers open the docs first
The factual pages are current every morning because they come from the tools. The server list matches the RMM. The procedures page for the finance system shows a flag: the application was upgraded last month, and the procedure has not been reviewed since. The client's documentation owner reviews it that week.
When the engineer who changed a firewall rule closes their ticket, they are shown the network page and asked whether it needs an update. It takes a minute. Over time, the team starts to trust the documentation again, and the question in team chat is replaced by a link.
It also helps with onboarding new engineers, who can learn a client from its documentation instead of shadowing the one person who knows it.
A useful side effect is a clearer picture of where knowledge is thin. The health score shows which clients have procedures nobody has reviewed in a year, or no procedures at all for the application that generates most of their tickets. The service manager can hand those to the engineers who know the clients best, one or two pages a week, instead of launching a documentation drive that fades after a fortnight.
Checklist: is your documentation trusted?
- Engineers ask colleagues before they check the documentation.
- Device and server lists in the docs disagree with the RMM.
- Procedures refer to menus or systems that no longer exist.
- Nobody can say which pages are out of date.
- Your documentation tool is mostly used for passwords.