A service level agreement, or SLA for short, is one of the contracts between a managed services provider and their client. This contract can either guide your client about the right way to communicate with you or lead you to penalties or court.
So it is of the utmost importance to outline each SLA carefully for each customer. However, SLAs are not unique; there are baseline principles that fit each service agreement and still benefit an MSP. In this article, we will define such principles, so you can review your service level agreements and make sure that nothing puts your company in danger.
What Is a Service Level Agreement?
A service level agreement is an agreement that defines the expected delivery of services by an MSP to the client. Since your customers are unique, you need to create and sign a custom SLA for each one. Also, a service level agreement is a contractual obligation and sometimes your customers want you to add penalties into it.
MSP SLAs typically state maximum ticket response time, support hours, ticket prioritization levels, escalation practices, and the maximum downtime for the piece of infrastructure that you are taking responsibility for. In other words, it sets an expectation of your services for the customer.
1. Create and Review Your SLA with a Lawyer
An hour of your lawyer's work for sure costs a lot. But it costs a lot less than going to court with your client because of a badly written service level agreement. Believe it or not, many of your clients will try to sue you whenever things get out of control or in the event of the first data breach or downtime. And if they have a lawyer, they will scan every inch of your SLA to find a way to demand a penalty from you.
Further reading The Importance of Legal Services to MSPs
If you are not sure how to create an SLA from scratch, there are plenty of service level agreement templates on the Internet. However, as we've already mentioned, each SLA should be heavily customized for your and your client's unique case. Once done, you should review the result with the lawyer to make sure that you are well protected.
2. SLAs Should Be Measurable and Documented
Some startup managed IT providers tend to only discuss the client's expectations and service delivery verbally, instead of putting them down on paper. As time goes by, you and your client will definitely forget about the exact figures and obligations you discussed, thus creating grounds for a dispute.
On the other hand, when you create an agreement, avoid using unmeasurable time frames. For example, if you tell your client that you will provide them support during ”normal business hours”, most probably they will interpret this as ”8 AM-10 PM, including weekends”, since ”normal” is not a measurement.
3. SLA Measurements Should Benefit You
One metric can be measured differently and you should choose a method that benefits you, rather than your client. For example, if you have a metric for the first response time, you can count that time in three different ways:
- from the occurrence of the incident;
- from the time you received the ticket;
- from the time you received the ticket, within business hours.
These three measurements can vary hugely. Let's say that your client had an issue on Saturday, sent you the support request on Sunday, but your normal business hours start at 10 AM on Monday. If you start resolving the issue on Monday at 10, then, going by the first two measurements, you will fail to meet your SLA response times.
4. SLA Is an Acknowledgment, not a Guarantee
The next crucial tip to remember is that your SLA is not a guarantee of resolution of an issue in the given time frame. It should rather indicate your acknowledgment of an issue. Why is that crucial?
Let’s imagine that you are recovering your client’s on-prem server after a disaster, and your SLA states that you have to recover it in less than 6 hours or you will pay a penalty. However, if there is an unexpected electrical issue, the lights go off or a similar issue, you won’t be able to recover the server in time – which gives your client an option to demand a penalty from you.
The other possible reason to not count the resolution time is when it turns out that the reason for the downtime is a firmware bug or a similar case and you need to contact the developer or vendor of the solution to get things fixed. In other words, you should not be responsible when you cannot control the situation.
5. Define the Client’s Violations
Some of your clients' end users will install solutions without your knowing about it. Sometimes they will use decommissioned hardware, change passwords against your recommendations, use unsecured connections, try to disable MFA, or tamper with backup settings. Some end users just want to see the world burn.
Your SLA should explicitly outline that any of the aforementioned actions, anything that your client does without your knowing and acknowledging these actions, makes their company fully responsible for their actions. Moreover, if a data breach or a downtime happens due to shadow IT practices, you should mention that you will require additional payment for helping them to recover.
6. Estimate Your Real Throughput
Lastly, you might want to impress your customers with blindingly fast response and resolution times. But if, in reality, your team lacks enough people to respond in under a minute on a 24/7 basis, such estimations will only lead to frustration for your clients, burnout for your tech staffers, and loss of reputation for you.
You should rather estimate a slightly higher response and resolution time than you normally do, in order to over-deliver in the eyes of your customers.
Conclusion
It might seem as though the tips above will help you to create a service level agreement that fools your client, but this is not true. As we've already said, some of your clients will happily take you to court for the first SLA violation. Also, an SLA that was built to benefit you helps you to protect your reputation as an MSP.
