The MSP SLA Template That Actually Protects You (And Why Most Don't)

Most MSP SLAs protect nobody. They're copied from a Reddit thread, wordsmithed by someone who used to sell copiers, and signed without anyone reading them.

Then a client server goes down at 2 AM. You respond in 20 minutes. They say that's not good enough. They expected full resolution by morning. You pull up the SLA. It says "best effort." They say that means nothing to them. Two hours later you're still on the call, walking them through work that isn't in scope and won't be on the invoice.

Good job. You just worked for free.

An SLA isn't paperwork. It's the mathematical boundary between what you owe and what you don't. Get it wrong and every incident becomes a negotiation. Get it right and the conversation is already over before it starts.

The 7 Clauses Most MSP SLAs Are Missing

Response vs. Resolution - Define Both, Separately

"Response time" means you acknowledged the ticket. "Resolution time" means it's fixed. These are not the same thing.

If your SLA says "4-hour response" and a client expects their email server restored in 4 hours, you have a gap. A gap is a lawsuit waiting for a bad day.

Write it out explicitly:

• Response time: The clock starts when the ticket is logged. You acknowledge within X hours. Acknowledgment means a human has read it and assigned it, not an auto-reply.
• Resolution time: Not guaranteed in most cases (and shouldn't be - some issues take days). If you do commit to resolution windows, define them per severity tier, not as a blanket promise.

If you don't define the difference, clients will assume resolution time whenever the word "response" appears. They're not wrong to. It's ambiguous.

Severity Tiers With Real Criteria

"Critical," "High," "Medium," "Low" means nothing unless you define what qualifies.

Bad: "Critical issues will be addressed immediately." Better: "Critical means complete system outage or data loss in progress. Multiple users unable to work. Security breach confirmed or suspected."

Every tier needs:

• What qualifies (specific examples, not vibes)
• Response window
• Escalation path
• Communication frequency during the incident

Three tiers is usually enough. More than four creates confusion. If your team can't quickly agree on which tier a ticket is, your tiers are too fuzzy.

Exclusions - Written Out, Not Buried

Your SLA is a promise about what you'll do. It also needs to say clearly what it doesn't cover.

Standard exclusions:

• Issues caused by client-administered changes (they installed something, you didn't)
• Third-party software vendor outages (Microsoft 365 goes down, that's Microsoft's SLA, not yours)
• Hardware you didn't supply and don't manage
• Natural disasters, power outages, ISP failures
• After-hours work beyond your defined coverage window

If you don't list exclusions, every exception becomes a fight. "Is this covered?" should have a binary answer, not a conversation.

Coverage Hours - Exactly When the Clock Runs

"Business hours" is not a coverage definition. It's an invitation to argue.

Define it:

• Monday through Friday, 8:00 AM to 6:00 PM Eastern (or whatever your zone is)
• Excluding holidays explicitly
• After-hours: emergency contact method, what qualifies as an emergency, and billable rate

If you have a tiered offering (standard vs. premium with after-hours), the SLA needs to reflect which tier applies to this client. One template for every client means every client has different expectations and the same document.

Uptime Commitments - Only If You Control the Infrastructure

Don't commit to uptime on infrastructure you don't control.

If you manage a client's on-prem servers, an uptime commitment is reasonable. If you're managing their Microsoft 365 tenant, you don't control uptime. Microsoft does.

If you promise 99.9% uptime on a cloud service you didn't build, you're promising something you can't deliver.

Uptime math, for reference:

• 99.9% = 8.7 hours of downtime per year
• 99.5% = 43.8 hours per year
• 99% = 87.6 hours per year

Commit only to what you can actually track, measure, and control.

Client Obligations

An SLA is a two-way document. Most MSPs write it like they owe everything and the client owes nothing.

Client obligations that belong in every SLA:

• Timely access to systems and credentials when tickets require it
• Designated point of contact who can approve work
• Notification within a defined window when users make changes that could affect managed systems
• Accurate inventory reporting (they tell you about new devices, departures, software purchases)

If a client won't give you VPN access for 72 hours and the ticket sits, you didn't breach anything. But if the SLA doesn't say that, they'll try to pin it on you.

Change Control and Scope Modification Language

When you add a service, change a pricing tier, or stop supporting something, the SLA needs a process.

Minimum required:

• 30-day written notice for any changes to service scope
• Mutual agreement for scope expansion (they can't just email "please set up 14 new computers" and assume it's covered)
• A process for one-time requests that fall outside managed services (project work, not help desk)

Without this, scope creep is silent and uncontrolled. You end up managing things you never agreed to manage, at rates you never agreed on, with no paper trail.

The 5 Common MSP SLA Mistakes

Mistake 1: Promising availability on services you don't host. You are not Microsoft. Don't sign their SLA on their behalf.

Mistake 2: One SLA for all clients. A 5-person accounting firm and a 200-person construction company have different risk tolerances. A single template means you're either over-promising to one or under-delivering to the other.

Mistake 3: Vague escalation paths. "We will escalate to senior staff" is not an escalation path. Name the roles. Define when escalation happens automatically.

Mistake 4: No measurement mechanism. If you commit to response times but don't have a ticketing system that tracks them, you can't prove compliance. SLAs need to be measurable or they're unenforceable. If your quoting and client operations feel similarly untracked, start here.

Mistake 5: Never revisiting them. SLAs signed in 2019 may not reflect your current tooling, team size, or service scope. If it's been more than 12 months since you looked, look now.

What a Complete MSP SLA Actually Looks Like

You need these sections, in plain language, not legal boilerplate:

1. Scope of services - what's included, what's not
2. Severity definitions - per tier, with examples
3. Response and escalation commitments - per tier, per coverage window
4. Coverage hours - explicit dates and times
5. Exclusions - specific list, not a catch-all clause
6. Client obligations - what they need to provide
7. Measurement and reporting - how you'll track performance
8. Change control - how scope and pricing can change
9. Termination conditions - what happens if either party exits
10. Review cadence - how often the SLA gets revisited (annually minimum)

Ten sections. Most MSP SLAs have four.

The Tool Problem

Most SLA advice skips this part. A good SLA is only as useful as your ability to execute against it.

If your PSA doesn't track response times by ticket severity, you can't prove compliance. If your ticketing workflow doesn't automatically escalate P1s, you're relying on someone to notice.

SLAs create accountability. Accountability requires data. Data requires tooling that captures it automatically.

Before you tighten your SLA language, audit what you're actually measuring. If you can't pull a report showing average response time by severity tier for the last 30 days, your SLA is a promise you can't verify.

FAQ

What's the difference between an SLA and an MSA?

Your MSA (Master Services Agreement) is the contract: payment terms, liability limits, intellectual property, dispute resolution. Your SLA is the operational agreement: service levels, response times, and what you actually do. Both are necessary.

Do I need a lawyer to write an SLA?

For the operational content, no. You know your services better than any attorney. For the legal wrapper (liability limits, indemnification, dispute resolution), yes, get it reviewed.

What should my SLA say about cybersecurity incidents?

Have a separate incident response section. A security breach is not a normal help desk ticket. Define when you declare an incident, your first response steps, when you involve outside IR support, and what gets documented.

How often should I update my SLA?

At minimum, annually. In practice, whenever you change tooling, add or drop a service, or change team structure.

Can I have a tiered SLA for different clients?

Yes. You probably should. Standard tier gets business-hours response. Premium tier gets extended hours and faster P1 response. Define tiers clearly and price them accordingly.

If your SLA currently says "best effort" anywhere, fix that first. Then work through the ten sections. The goal isn't a perfect legal document. The goal is a document that makes every incident conversation shorter. For MSPs sorting out broader quoting workflows, this comparison is a useful next read.

If you are rebuilding the commercial side of your service agreements too, join Scopable early access.