Documentation Standards

Last updated

Documentation is an asset, not admin overhead

Every MSP says documentation matters. Very few treat it like the asset it is. Good documentation is what lets a second tech resolve a ticket without pinging the first, what lets you take a vacation, what makes a new hire productive in weeks instead of months – and, at exit, what a buyer's due-diligence team actually reads to decide whether your client base is transferable or trapped in your head. Documentation quality is also becoming the ceiling on automation gains: AI-assisted triage escalates to humans exactly where docs are sparse. The MSPs getting real gains from automation as of 2026 are the ones whose documentation was already disciplined.

This guide covers what to document per client, where to keep it, how to name it, and – the hard part – how to keep it alive.

The per-client minimum set

Every client should have the same core documentation, structured identically, regardless of which tech built it. The minimum set:

  • Network diagram / topology. Firewall, switches, VLANs, servers, key SaaS dependencies, site-to-site links. Auto-discovery helps (IT Glue's Network Glue; Hudu pairs with embedded Lucidchart or auto-diagram tools) but a human should validate it.
  • Credentials – in the vault, nowhere else. Admin accounts, local admin, firewall/switch logins, service accounts, API keys, and MFA recovery codes. Never in spreadsheets, never in ticket notes. This is also what makes clean client offboarding possible: you can only rotate what you can enumerate.
  • ISP and vendor information. Account numbers, support numbers, circuit IDs, contract and renewal dates. The 2 a.m. outage is not the time to hunt for the circuit ID.
  • Licensing inventory. M365 tenant and SKUs, line-of-business apps, keys, renewal dates.
  • Backup configuration. What is backed up, on what schedule, with what retention, where restores are tested, and who receives alerts. This document is the first thing anyone should check in a recovery scenario – see the backup and DR process.
  • Asset inventory synced from the RMM, with warranty status.
  • Runbooks and SOPs linked to ticket types – "what to do when X" – each with an owner and a review date. A runbook tied to a recurring ticket type is the cheapest efficiency gain in the business.
  • Site information. Physical access procedures, alarm codes, key contacts, VIP list, and the approved-requester list (who may authorize changes or password resets – a social-engineering control, not a courtesy).

If a client folder is missing any of these, that gap is a finding to fix, not a permanent condition.

Documentation is an onboarding deliverable

The single best structural decision: treat completed documentation as an explicit deliverable of client onboarding, with a due date, not something that accretes over years of tickets. During onboarding days 1–30 you are already doing discovery – assessment, asset inventory, access validation, backup checks. Capturing that into the standard structure while you're in there costs a fraction of reconstructing it later. Onboarding isn't done until the client's documentation passes your own checklist.

Where to keep it: IT Glue, Hudu, and structure

Use a dedicated documentation platform with a credential vault – not SharePoint, not a wiki, not the PSA's notes fields. The two names that dominate the conversation as of 2026:

IT Glue – Pros: market leader, deep integrations across the Kaseya suite, Network Glue auto-discovery. Cons: Kaseya-owned (a factor if you avoid that suite), 5-user minimum makes it pricier for very small shops. Best fit: MSPs already in or comfortable with Kaseya tooling.

Hudu – Pros: the popular independent alternative, cheaper, self-hostable, includes a vault. Cons: lighter native auto-discovery; you assemble more yourself. Best fit: small independent MSPs and anyone wanting to own their data location.

Either way, the structure matters more than the tool (as with the rest of your tool stack). Build standardized templates – one flexible-asset template per documentation type (ISP, LOB application, backup config, site info) – so every client is the same set of typed records, not freeform pages. Identical structure is what makes documentation searchable, auditable for gaps, and usable by a tech who has never touched that client.

Naming conventions

Agree on conventions once, write them down as an internal SOP, and enforce them in review:

  • Prefix by client code. A short unique code per client (e.g., ACME) leading every asset name: ACME-FW01, ACME-DC01.
  • Predictable device names. Role + number: FW, SW, DC, FS, HV. A tech should know what ACME-SW02 is before opening the record.
  • Credential titles that state system + account, e.g., ACME-FW01 admin, M365 Global Admin – break-glass. "Password 3" in a vault is barely better than a sticky note.
  • Runbook titles that match ticket types, so the runbook surfaces when the ticket is categorized.
  • No orphan documents. Every page belongs to a template type and a client. If it doesn't fit, either the taxonomy needs a new type or the document doesn't belong.

Keeping documentation alive

Stale documentation is worse than none – a tech who trusts a wrong credential or an outdated diagram loses more time than one who knows to go look. Three practices keep docs alive:

  1. Review dates on everything. Every runbook and core record carries an owner and a next-review date. Work reviews as scheduled tickets, monthly batch by client. Onboarding new staff doubles as an audit: have them follow the runbook literally and flag every place it lies.
  2. Documentation time is logged, expected work. It goes against tickets and agreements like any other time, and it is incentivized – never treated as what techs do "when things are quiet." Things are never quiet.
  3. "Doc it or it didn't happen" culture. The same rule that kills the shoulder tap in ticket management applies here: a fix that isn't captured – in the ticket resolution, and in the runbook if it will recur – will be re-solved from scratch by the next tech. Make the update part of closing the ticket, not a separate virtuous act.

Documentation as company value

At exit, buyers price the difference between a business and a founder-with-clients. Strong documentation is evidence that service delivery is transferable: any competent tech can support any client from the record. Thin documentation reads as key-person risk and gets discounted accordingly – the same way month-to-month handshake deals do. The identical logic applies at smaller scale: every internal handoff, every new hire, every vacation is a miniature exit, and documentation is what makes it uneventful. And when a client relationship ends, complete records of what you held and what you rotated protect you if a claim or audit lands a year later.

Where to start

Don't boil the ocean. Pick your top three clients and build the full minimum set for each using standardized templates – that forces you to design the templates properly. Then make the completed set a hard exit criterion of onboarding for every new client, and schedule the first quarterly review tickets. Within two quarters you'll have the structure, the habit, and a documentation platform that is worth what you pay for it.