What actually needs to be documented
Customer environments and systems. What exists, where it runs, and how it all connects.
Procedures and runbooks. How recurring tasks are performed, written so that someone other than the author can follow them.
Dependencies. What stops working if a specific service goes down.
Contact and escalation paths. Who to contact at the customer, and in what order.
Sensitive information. With access control, and preferably in a system built for the purpose. See password and access management.
Documentation, CMDB, and knowledge base
Three concepts that are often confused.
A CMDB is a structured register of components and dependencies. It answers the question of what is affected when something changes.
IT documentation is the descriptive part: routines, context, and the knowledge that would otherwise only exist in someone's head.
A knowledge base is aimed at those who resolve tickets, and sometimes at end users. It answers the question of how to do something.
They overlap and should be linked to one another, but they solve different problems and should not be forced into the same structure.
Anything updated by hand will become outdated
The crucial factor is not how documentation is written, but how it is maintained.
Connect your documentation system to PSA and RMM so that customers, sites, users, and devices are synced automatically. Let automation workflows update the documentation as part of the process – when a user is added or offboarded, the documentation should be updated without anyone needing to remember to do it.
Anything that requires manual input will become outdated. The only question is how quickly.
Structure before content
A documentation system set up without a well-thought-out structure becomes an archive rather than a working tool, and it is significantly more difficult to fix after the fact.
Define templates, naming standards, and ownership before you start populating the system. Start with the customers or systems where knowledge is currently most dependent on specific individuals – that is where the risk lies.
Knowledge management
Resolved tickets become articles, and articles lead to fewer tickets. The effect is twofold: technicians find answers faster, and users resolve some issues themselves via the self-service portal in the service desk.
This only works if the article can be written the moment the ticket is resolved. If it requires switching to another tool, it won't get done.
