IT documentation best practices start with a record another technician can use without asking its author. For example, a client's scan-to-email ticket needs the current credential, device details and vendor contact in one accessible record.
I'd start with a fixed list: six things every client needs in writing, stored where your team can reach them, and a quarterly review to keep the list current. The aim is to give an engineer unfamiliar with the client the information they need to take over.
The Six Things Every Client Needs in Writing
My view is the list has to be short or no one will maintain it. Every item has to be something an engineer actually needs on a bad day. Six items cover it.
- Network diagram: switches, firewalls, VLANs, internet circuits, and where the patch panel goes. Include physical locations, not just IPs.
- Credentials: every one of them, not just admin accounts. That means scan-to-email passwords on the MFD, service accounts in line-of-business apps, and the Wi-Fi passphrase. One operator described including scan-to-email credentials in handover because they expected the receiving team would otherwise need to reset them.
- Vendor contacts and renewal dates: who to call for the copier, the phone system, the ISP, and when each contract renews. A missed renewal is a surprise bill you don't want.
- Hardware and software inventory: make, model, serial number, warranty status, and which user has what. Keep the information needed for a replacement decision.
- Offboarding and onboarding notes: who left, who joined, what access was revoked, and what was set up. This is the history that explains why a stray account still exists.
- Who to call escalation path: the client's decision-maker, the after-hours contact, and the order in which you're allowed to wake people up.
Store the list in your PSA or a structured wiki, and make it a mandatory field before a ticket can be closed. If a ticket closes without the checklist being touched, the list dies.
The Quarterly Review That Retires Dead Documentation
Once the list exists, the problem becomes staleness. Picture a client changing offices and phone systems after onboarding. I'd budget a 30-minute quarterly review per client, owned by the service manager or a designated senior tech, going through the checklist line by line and fixing anything that's outdated.
Block it on the calendar and do not skip it, even if no tickets came in. The review is what catches the scan-to-email credential that changed in a routine password rotation, before a handover turns it into a crisis.
For high-change clients, consider monthly rather than quarterly review. Check the time needed against the amount of change rather than assuming the same slot will cover it.
Cost it honestly: budget roughly 30 minutes per client per quarter, plus the initial documentation time per client. That is a proposed allowance, and you should set it against your own figures. Measure the initial work before assigning the remaining clients.
Who Owns the Review When the Owner Is Away?
Assign the review to a service manager or senior technician and name a backup for absences. Record who is responsible for resolving the gaps it finds.
Designate a backup reviewer. In a 5-person shop, that might be the other senior tech. In a 40-person shop, you could rotate the review among engineers, with the owner checking the work. If the service manager is on leave, give the backup a named client list and agree who will handle the rest.
I'd also consider pairing a junior and a senior tech to review each other's documentation. Ask the junior to flag unexplained assumptions and the senior to check what is missing.
When the Checklist Is Not Enough
The list and the review fail in three places, and you should know what they are.
First, when the client changes faster than the cycle. If the client is changing weekly, no quarterly review will keep up. That's when you push for monthly, or you accept that the documentation will lag and you budget for the cleanup.
Second, when credentials are stored insecurely or not updated after a change. If you keep them in a spreadsheet on a shared drive, or you don't update a password when it rotates, the checklist is worse than useless. It's a false sense of security. Use a proper password manager or a PSA that encrypts secrets, and make the update a part of the change ticket.
One operator described an outgoing provider withholding a physical AD server on the basis that it was rented to the client. The operator reported that the client bought a replacement and migrated before the old provider stopped billing.
If an outgoing provider withholds hardware or access, plan for a migration to new gear rather than fighting. Have your lawyer clarify ownership and billing obligations while you plan the technical handover.
Monday's First Move: Pick Five Clients and Start
Start with the five clients with the most tickets and run the checklist for each. Schedule the first quarterly review for each one, and assign the initial documentation work to a named person.
For the scan-to-email client in the opening example, check the credential in its secure store and record the vendor contact. Then work through the same list for the remaining clients.
mspoutpost.com/articles/it-documentation-best-practices-for-every-msp-client
Written by Megan Friesen
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.
