Documentation & SOPs

Knowledge Base Structure Template for MSPs

A practical template for organizing client knowledge bases with consistent hierarchy, naming conventions, and required fields. Designed for IT Glue, Hudu, or any structured documentation platform.

Template Â· Updated Feb 2026

By MSP Workflows Team

Contents

1.Structure Before Content
2.Recommended Client Hierarchy
3.Naming Conventions
4.Required Fields for Every Record
5.Common anti-patterns
6.When migrating to a new platform
7.Should every MSP use the same hierarchy?
8.How do you prevent documentation sprawl as the team grows?
9.What about internal MSP documentation (not client-specific)?

Structure Before Content

The single biggest mistake MSPs make with documentation is adding content before defining structure. A knowledge base with 500 well-written articles and no organizing hierarchy is almost as useless as no knowledge base at all, because nobody can find anything. Define your folder hierarchy, naming conventions, and required fields before importing a single record. It takes a few hours upfront and saves hundreds of hours of searching, reorganizing, and deduplicating later.

Recommended Client Hierarchy

Organize each client's documentation using a consistent hierarchy that every technician on your team can navigate without training. Start with the client root. Under that, create standard sections: Overview (client profile, contacts, SLA details), Network (diagrams, IP addressing, firewall rules, VPN), Servers (per-server documentation with linked credentials), Endpoints (workstation standards, deployment procedures), Cloud Services (M365 tenant, Azure/AWS configuration, SaaS subscriptions), Credentials (linked from the vault, organized by system), Backups (configuration, schedules, restore test records), Security (AV/EDR, MFA, email filtering, incident history), Vendors (support contracts, contact details, renewal dates), and SOPs (client-specific procedures and runbooks). Every client gets the same hierarchy. Even if sections are initially empty, the structure is in place for when the content arrives.

Naming Conventions

✓Client names use official business name, not abbreviations or nicknames
✓ Server names match the actual hostname in the environment
✓ Documents follow a consistent format: [Client] - [System/Topic] - [Document Type]
✓ Credential entries include the system name and access method
✓ SOPs include a version date in the title or metadata
✓ Network diagrams are dated and include the revision number
✓ Tags or categories are drawn from a controlled list, not freeform

Required Fields for Every Record

✓Owner (who is accountable for this record's accuracy)
✓ Last updated date
✓ Review cadence (how often this record should be verified)
✓ Client and location association
✓ Related records (linked credentials, devices, SOPs)
✓ Confidentiality level (internal, client-visible, restricted)

Common anti-patterns

Unstructured note dumps where technicians paste whatever they want with no hierarchy. Duplicate records for the same system created by different technicians who didn't check first. Orphaned records that aren't linked to any client, device, or SOP. Documentation in multiple locations (some in the platform, some in SharePoint, some in email). All of these indicate a structure problem, not a content problem.

When migrating to a new platform

Don't migrate everything. Define your target structure in the new platform first. Then migrate only active client documentation that meets your completeness standard. Archive everything else. Migration is an opportunity to clean house, not to transfer mess from one system to another.

Should every MSP use the same hierarchy?

The specific sections may vary, but the principle of consistent, client-rooted hierarchy is universal. Customize the sections to match your service offering, but apply the same structure to every client. Inconsistency across clients means technicians have to learn a new layout for every client they work on.

How do you prevent documentation sprawl as the team grows?

Enforce required fields and naming conventions at the platform level (not just as policy). Use templates that pre-populate the correct structure. Assign documentation review as part of the QA process for ticket closure. And run quarterly audits that flag records missing required fields, orphaned records, and duplicate entries.

What about internal MSP documentation (not client-specific)?

Maintain a separate internal knowledge base with the same structural discipline. Organize by function: onboarding procedures, tool configuration guides, escalation procedures, vendor management SOPs, and training materials. The internal KB is where you capture institutional knowledge that doesn't belong in a client record.

← Back to all guides