MSP Documentation Roles: What Tier 1, 2, and 3 Techs Should Be Writing

Let’s be honest. Documentation at most MSPs tends to fall into one of three categories: “This is great, but who wrote it?”, “Wait, is this still relevant?”, and “Why do we have six versions of the same process, none of which actually work?”

When everyone writes everything, no one owns anything. That’s why smart MSPs divide documentation responsibilities based on tech tiers. Because the Tier 1 tech resetting passwords all day shouldn’t be drafting your disaster recovery SOP, and your Tier 3 architect probably shouldn’t be documenting how to uninstall Zoom.

In this blog, we’ll break down exactly which types of documentation should be written by Tier 1, Tier 2, and Tier 3 technical staff. It’s time to turn chaos into clarity, one well-tagged wiki entry at a time.

Understanding Documentation Types in MSPs

Before we start handing out writing assignments, let’s identify the three core types of documentation most MSPs produce:

• Operational: The tactical, “how-to” stuff used daily to keep the lights on.

• Tactical/Escalation: Deeper, system-level fixes, often used by Tier 2 when Tier 1 runs out of magic.

• Strategic: SOPs, architecture diagrams, project documentation, anything that would make a CISO nod in approval.

Tier 1 – Tactical, Operational, Frontline Documentation

Tier 1 is your first line of defense. These folks answer phones, reset passwords, and occasionally act as therapists for angry users who “swear” they didn’t do anything.

What they should be documenting:

• Quick-reference guides and repetitive task walkthroughs.

• Simple KB articles based on frequent tickets.

• Notes that help other Tier 1s resolve similar issues.

Examples include:

• “How to unlock a user account in Active Directory”

• “Steps to reinstall Office 365”

• “How to map a network printer on Windows 10”

Golden Rule: If it’s the kind of task that gets done five times a day, it belongs in Tier 1 docs.

Bonus Tip: Tier 1s are closest to the chaos. Encourage them to log undocumented steps. Even rough notes are better than tribal knowledge.

Tier 2 – In-Depth Troubleshooting & Escalation Documentation

When the “Have you tried turning it off and on again?” approach fails, it’s Tier 2’s time to shine. They’re the bridge between basic support and full-blown engineering.

What they should be documenting:

• Troubleshooting procedures for common escalations.

• Escalation criteria and decision trees.

• Admin tasks that don’t require deep architecture knowledge.

Examples include:

• “How to diagnose DNS resolution failures on a client network”

• “Step-by-step guide to repairing a corrupted Outlook profile”

• “Escalation SOP: When to involve Tier 3 for server failures”

Golden Rule: Tier 2 docs should pick up where Tier 1 left off. Think triage, troubleshooting, and workflows that make escalation seamless.

Bonus Tip: Let Tier 2s review and clean up Tier 1 submissions before they go live. It keeps the knowledgebase lean and accurate.

Tier 3 – Strategic & Project-Level Documentation

These are your heavy hitters. Tier 3 engineers and architects design systems, implement infrastructure, and curse auditors under their breath.

What they should be documenting:

• SOPs for critical infrastructure and change management.

• Network diagrams, onboarding packets, and project handoffs.

• Configuration standards for things like firewalls, servers, and cloud environments.

Examples include:

• “SOP: Implementing MFA across hybrid environments”

• “Network design and VLAN segmentation plan for Client X”

• “How to install and configure LOB application Y with SQL backend”

Golden Rule: If it impacts the business, client compliance, or core infrastructure, it belongs to Tier 3.

Bonus Tip: Tier 3s don’t always love writing. Make it easier by assigning templates, version control systems, and, if necessary, bribery.

Collaboration & Review Workflow

A great documentation strategy isn’t just about who writes what, it’s about how those documents evolve.

Follow this general flow:

1. Tier 1 drafts frontline articles and tickets.

2. Tier 2 reviews, edits, and escalates recurring patterns.

3. Tier 3 publishes strategic documentation and approves SOPs.

4. Everyone can flag outdated or inaccurate entries.

Use a central knowledgebase or PSA-integrated wiki. Tag documents by tier, type, and date. And for the love of efficiency, retire old docs like you would a failed backup server, quietly, but with purpose.

Benefits of Role-Based Documentation Ownership

When each tier focuses on their zone of genius:

• Tier 1 resolves more tickets without escalation.

• Tier 2 focuses on advanced support, not basic triage.

• Tier 3 spends less time cleaning up messes and more time building scalable systems.

It’s not just about better documentation, it’s about running a smarter, leaner MSP that scales without drowning in duplicate PDFs and half-finished OneNote pages.

Pitfalls to Avoid

• Don’t assign SOP creation to Tier 1 just because they have the time. It won’t end well.

• Don’t expect Tier 3 to document every support process. That’s not their job.

• Don’t skip peer reviews. Even great techs miss things.

• Don’t wait until something breaks to document it.

Treat documentation like preventive maintenance, not post-incident therapy.

How to Implement This in Your MSP

1. Audit your existing documentation and tag each by tier and type.

2. Assign tier-level documentation responsibilities in onboarding materials.

3. Create templates for each doc type. Make writing as painless as possible.

4. Use regular reviews and feedback loops to keep content accurate.

5. Celebrate clean, updated documentation. Yes, seriously.. make it a KPI.