The customer is always right, said someone somewhere once.
But as MSPs we all know that not only is the customer not always right, letting them make any demands they want is a road to business ruin.
That’s where MSP SLAs—service level agreements—come in.
What’s an MSP SLA?
An SLA is an agreement between you and your client that clearly defines the scope of services you’ll provide. Among other things, it outlines when and how support can be accessed, what resolution times you commit to, and what happens when there’s an SLA breach.
You can and should use an SLA no matter what your MSP billing model. Whether you’re offering all-you-can-eat service contracts, break-fix services, block hours, or some combination of those, there needs to be clarity on what you’re delivering and how you’re delivering it.
As Comptia notes, a well-crafted SLA can be “the ultimate source of your profit and protection.”
Do you really need an MSP SLA?
Yes! No matter how big or small you might be—even if you’re a solo operator—an SLA is one of those foundational business tools you need in place from the beginning.
Why?
SLAs protect you and your MSP business. A clear SLA keeps you safe from out-of-scope requests and unreasonable service expectations, both of which can negatively affect your profit margin. SLAs can also protect you legally, which often comes into play with security issues. For example, your SLA might stipulate that your MSP can’t be held liable for a security breach if the client doesn’t implement the security protocols you’ve recommended.
SLAs provide clarity for both you and your client. Clients appreciate knowing what they can expect from you and when. By including penalties for non-compliance, you’re asurring them you’ll be working hard to meet those expectations. On your side, clarity on what’s in scope is fantastic for your team, who can then focus on the jobs to do and not on negotiating with clients.
SLAs help you look professional. SLAs speak to your reliability as a service provider. Clients want this kind of reassurance. Especially if you’re a smaller MSP, an SLA can demonstrate that you’ve got your ducks in a row and know what you’re doing.
What does an MSP SLA include?
What’s covered and not covered
Clearly outline the services you’ll provide, along with an inventory of any hardware or software that’s part of the package. Also outline what you don’t cover.
Support hours
Document when your team is available for support, as well as what a client should do when there’s an issue outside of those support hours.
Uptime promises
What’s your commitment to keeping your client systems up and running? Be both realistic and specific. What you need to promise may vary depending on the industry you’re serving. A hospital might need stronger uptime guarantees than a florist, for example. A hospital might also need 24×7 uptime, while the florist needs just 8×6. You may also want to specify different uptimes for different services, such as email vs point of sale.
How to report issues
Specify the different approved ways a client can open a ticket with you. The options may vary depending on whether the request comes inside or outside of support hours.
Issue classifications
In the eyes of your client, every issue might seem important and urgent so you’ll likely want some parameters to help them define what’s a fire and what’s not. For example, you might define a critical system or equipment failure, like a server crashing or the Wi-Fi going down, as a Priority 1 issue, but not being able to merge two Word documents as a Priority 4.
Resolution times
Here’s where you set expectations around how quickly you’ll respond to issues. The content in this section may be determined by:
- What kind of plan they’re on (e.g., managed service clients get faster times than break-fix clients)
- What package they purchased (e.g., the gold plan gets faster service then the bronze plan)
- The issue severity (as outlined in your issue classifications)
Resolution time modifiers
What happens if you can’t address an issue because of something specific to the client? If you need on-prem access to a router but security won’t let you into the building on the weekend, there’s not a lot you can do but wait until Monday. Consider including some language about these types of situations to buffer resolution times.
Non-compliance remedies
What happens if you breach the SLA? Unless there are specific remedies outlined in the agreement, a breach can result in further disputes with the client about what comes next. The most common remedy is an applied credit on the next invoice. Your remedy clause should include how the credit amount will be calculated. Here’s an example from Contract Standards:
For each full percentage point less than the System Availability percent, the Client shall receive a service credit in the amount of 5% of the monthly service fee, up to a maximum of 30% to be applied to the next month’s service fee.
Client obligations
An SLA is a two-way street. Detail what your clients need to do to uphold their side of the agreement. This might include upgrading hardware that can no longer be patched or implementing certain policies and procedures. Make sure they review and explicitly agree to this section.
Protection of sensitive information
Your SLA should include a section on what you’ll do to protect your client’s proprietary or sensitive information. This could be anything from staff members’ personal records to credit card numbers or health files. Define your security protocols and include what actions you’ll take in the event of a security breach.
Liability limitations
An SLA is a legal document after all so you’ll want a section that indemnifies you and your employees and protects you from third-party liability.
A way out
Your SLA needs a termination clause that outlines how either you or the client can end the agreement. It’s a good idea to factor in time for you to remove or uninstall equipment or software, and wrap up your operations. Also specify what you’ll do (or not) if there’s a transfer to another MSP.
A word about subcontractor SLAs
I’ve been talking here about SLAs with clients but if you’re engaging subcontractors or partnering on client work with another MSP, you’ll definitely want an SLA for those situations as well. When the client calls to say something wasn’t done, you don’t want to be pointing fingers at each other saying, “Weren’t you supposed to do that?” and be left arguing over who has to fix it.
Final tips for drafting your MSP SLA
- Some member groups offer MSP SLA templates. The Tech Tribe and CompTIA are two good ones. You can use these templates as a starting point or to grab ideas but you’ll always want to customize the document to your business.
- Your SLA doesn’t have to be pages and pages of eye-watering legalese. Plain language contracts are just as enforceable and you’d be amazed at how much they’re appreciated by clients.
- Your SLA should be reviewed by a lawyer to confirm its validity and protections before you put it into use.
Once you’ve got your SLAs in place, you can use Syncro to track how you’re doing on response and resolution times by using the Contracts module. Not yet using Syncro? Start your free trial here to explore managing contracts and MSP SLAs in detail.
)
)