It's 11pm, the on-call phone rings, and the ticket says 'printer down' for a client you've never touched. You open the documentation and find a network diagram from three years ago, a login that no longer works, and no vendor contacts. The printer is a scan-to-email MFD, and the credential that feeds it is nowhere in the file. You'll spend the night breaking and resetting passwords on a device you can't reach remotely.
The fix is not a bigger wiki. It's a fixed, minimal list of what every client needs in writing, and a quarterly review that makes the list true. If you do that, a new engineer can run a client without a single phone call. Here's the list, and here's the routine that keeps it honest.
The Six Things Every Client Needs in Writing
My view is that 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 the 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. If it's not written down, the next engineer breaks it and resets it.
- 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. You need this for a replacement decision at 2am.
- 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 scan-to-email example is the one I keep coming back to. A missing credential for a device that sits in a client's back office is a 90-minute call for a tech who has never seen the device. The list prevents that, because the item is right there.
The Quarterly Review That Retires Dead Documentation
Once the list exists, the problem becomes staleness. A client that was stable in January has a new office, a new hire, and a new phone system by April. The answer is 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, those that hire every month or move offices twice a year, a quarterly cycle is too slow. Do a monthly review for those. The same 30 minutes, just more often.
Cost it honestly: roughly 30 minutes per client per quarter, plus the initial documentation time of a few hours per client. For a 20-client MSP, that's a day of review every quarter. It's not free, and it's not optional if you want the list to stay true.
Who Owns the Review When the Owner Is Away?
The review only works if someone is accountable for it. Name a single owner, the service manager or a senior tech, and hold them to it. But what happens when that person is on holiday or out sick?
Designate a backup reviewer. In a 5-person shop, that might be the one other senior tech. In a 40-person shop, you can rotate the review among engineers to spread the load, with the owner checking the work. If the service manager is on leave for two weeks, the backup runs the review for the top five clients, and the owner catches up on the rest when they return.
The pairing idea works too: a junior and a senior tech review each other's documentation. The junior catches what the senior assumes, and the senior catches what the junior missed.
When the Checklist Is Not Enough
The list and the review fail when the client changes faster than the cycle, when credentials are stored insecurely, or when the outgoing provider withholds access.
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.
Credentials must be stored securely and updated after every 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.
The other failure is the outgoing provider. You can have perfect documentation and still lose the physical server because the old MSP claims it's theirs. That's not a documentation problem, that's a legal one, and if the hardware is the client's property it's worth a call to your lawyer. If the old provider refuses to hand over hardware or access, plan for a migration to new gear rather than fighting. It costs more, but it ends the billing cycle.
Monday's First Move: Pick Five Clients and Start
Don't try to document every client at once. That's a project that dies by Friday. Pick the five clients with the most tickets, the ones where your engineers are most likely to be stuck at 11pm, and run the checklist for each. Schedule the first quarterly review for each one before you close the week.
The scan-to-email client, the one that keeps you up, is probably in the top five. That's the one to start with. Write the credential down, test it, and put the vendor contact next to it. Then do the same for the next four.
That's the whole move. Five clients, one list, one review scheduled. By the end of the quarter, every client you actually serve will have a file that a stranger can pick up and run with.
mspoutpost.com/articles/what-every-client-needs-documented-and-the-review-that-keeps-it-true
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.
