As an MSP, we’ve all been into complex situations at least a few times. Let’s take a look at a typical support call. An MSP gets the call to resolve an IT problem. The MSP team member rushes to resolve the issue as quickly as possible, but for some unknown and inexplicable reason, the client remains unhappy, because they feel that the issue at hand should have been resolved much more quickly and efficiently than the MSP team member did. At times, the MSPs try to go the extra mile and fix a problem that was not even in the scope of work but the client thinks that it was just your job. Such scenarios are frustrating for MSPs and no one on earth would ever want to be in such a situation.
The real problem is simply a disconnect between how the MSP thinks of the ways they should be servicing a client and how the clients think their MSPs should act. Here effective communication is the key—and can help resolve some of these problems. However, MSPs can’t count on their sharp memories all the time. Neither would documenting each client’s expectations on a notepad help. What MSPs need is a Service Level Agreement (SLA). The SLA serves as the core document that defines exactly the services they will provide to the client and sets client’s expectations around those services. In short, the SLA is a documentation of what each of what the client and the MSP are looking to get from each other.
In this article, we’ll cover what is an SLA, why do MSPs need an SLA, when should they—and shouldn’t—have one, what should be included, considerations when writing an SLA, and how to make SLAs measurable.
What is an SLA?
As per the definition, “An SLA is a contract between parties that defines the services provided, the indicators associated with these services, acceptable and unacceptable service levels, liabilities on the part of the service provider and the customer, and actions to be taken in specific circumstances”.
Why Do MSPs Need SLA?
Some of you may still think you can run your business without one. The most successful MSPs will adamantly disagree with you. There are some very compelling reasons why you need an SLA:
SLAs clarify obligations of the MSP
MSPs have control over clients’ key applications and IT infrastructure that includes many software and hardware devices. Additionally, depending on the scope of contract, MSPs might control various aspects of the client’s networks. However, there are many enterprise applications within the organization that are implemented and supported by the vendor that provides the application. For example, a company that has standardised on microsoft or oracle or IBM stacks might have given the contract for the ongoing support to the company that implemented those applications. Similarly, many applications that are cloud-based are completely taken care of by the cloud service provider. For example, if there are issues with the Salesforce CRM, the client would have to reach out to Salesforce support team.
An SLA clearly defines what would be the role of the MSP. And what would NOT be under the purview of the managed service provider. So, if an organization uses multiple applications from various vendors, the MSP most likely would not be expected to troubleshoot application specific requests. However, if the issue is with respect to some malware, the MSP might need to pitch in.
SLAs clarify the obligations of the end user
Sometimes issues crop up due to certain activities due to the end user. For example, installation of unauthorized software or use of external storage devices containing vulnerabilities, clogging of the network due to download of large files such as a video file, etc. A well defined SLA must take into account account such situations and clarify that it is the obligation of the end user to refrain from such activities. And in the event of such activities by end users lead to disruption of the work, then the MSP should not be held accountable.
SLAs helps MSPs in managing time and reducing staff fatigue
There are always a few individuals in every IT department, or in the client company in general, who have the tendency to push the panic button even when there are no major issues at all. This becomes annoying when you receive calls during odd hours when you are not supposed to be working. If working days and hours are clearly mentioned in the SLA, then the MSPs may postpone responding to such calls to the next day. Smaller MSPs usually do not have a large workforce and no 24/7 operation. In such cases, calls at odd hours may lead to the fatigue of the MSP support staff. Hence, by clear definition of time, SLAs will protect a lot of your time.
SLAs help resolve disputes and provide protection
There are times when some specific clients fail to meet their obligations such as blaming the MSP for IT related issues leading to business interruption and loss. If the obligations are clearly defined in the SLA and if the adherence of SLA is communicated through timely reporting and the reports are stored, such claims may not hold good. Such issues can be resolved by discussing the terms and conditions outlined in the SLA. Even if the situation becomes complex and the clients seek legal remedies, their claims, if not valid, would stand null and void thereby protecting the MSP from big and complex legal battles.
When should an MSP go for an SLA?
Almost always. An SLA is absolutely required. There is certainly a need for MSPs to set a customer’s expectations so that they don’t come to expect you to deal with every service request at the drop of a hat. And as we discussed above, SLAs can help clarify the obligations of the end user, help MSPs in managing time and reducing staff fatigue, and most importantly, help resolve disputes and provide protection.
So the answer is – MSPs should always go for an SLA.
However, surprisingly, there are situations when MSPs should refrain from signing complex SLAs. We will discuss these situations in the next section.
When should an MSP NOT go for an SLA?
It may seem totally weird to suggest to an MSP that it is in their best interest to avoid SLAs in some situations. Here are some examples:
If you are picking up the contract after the departure of a previous support provider
The previous MSP might have left because of several reasons. However, one of the reasons can be the fact that they were unable to meet the expectations of the client in many ways. There is also a possibility that the previous support provider ill-managed the IT infrastructure. There is a possibility that the vendor left because the infrastructure had gone old and out-dated and the company did not want to spend money on upgrading it and still expecting the MSP to deliver. In any of these situations where the systems were badly managed, neglected or required revamping, the new MSP would need time and efforts to bring the system back to a stable condition. This may not just take time but may require the client to spend money as well. Hence, outrightly signing an SLA may put the MSP in a difficult position. In such a case, the best idea would be to take the buy in of the management to first bring the system to be managed upto the speed and then sign a formal agreement.
If you find the customers to be an unrealistic and difficult in the first few discussions
There are clients or some members of the client’s team dealing with the MSP that have the habit of putting unrealistic expectations from the MSP with the limited technology investment. They always fail to agree that to be able to get a world-class IT infrastructure, they do not just need an MSP but also need to spend or increase their IT budget. Additionally, such clients take to blaming the MSP for the issues that are supposed to be the client’s obligations. A lot of customers do not understand the nitty gritty of IT services management, yet tinker with status quo making things worse. A lot of time businesses need to work on gut feeling. If during initial conversations, you realize that you’re dealing with such prospective clients, the best would be to either walk away or do not sign an SLA. Although if SLAs are stringent and well defined, clients may not blame the MSP or set unrealistic expectations from them. However, it is better not to get into such a situation as these clients and situations constantly drain energy and demotivates the MSP staff.
Requests of Informal arrangements instead of a comprehensive SLA
Many times smaller MSPs need to get into informal arrangements with other companies where they swap their services. For example, an MSP agrees to take care of the IT systems of an accountancy firm that provides accounting services to the MSP in lieu of the IT services it receives. There can be occasions where IT services providers trade off their services with a facility management company that offers its facilities to the MSP at a very reasonable cost. In such arrangements, undergoing an SLA may lead to increased responsibilities for the MSP. At times, they end up working fixing the IT environment of their accountancy or facility management clients incurring huge costs whereas the cost of accounting services received or the cost of the facility would have been much lesser. Although SLAs should be completely avoided when the arrangements are so informal. However, if required, the MSP should sign a very basic SLA and limit itself to providing just the bare minimum services required to keep the system up and running.
Although SLAs should be a must for every MSP as a rule. However, we need to understand that there are always exceptions to the rules.
What should be in an SLA?
Basic SLAs should have deliverables such as the support of the network, hardware or software, percentage uptime or permissible downtime, exclusions, response time, etc. However, when it comes to SLAs each of these deliverables, and much more, should be detailed to the extent possible. Here’re two key areas that should be included in detail in a SLA – service definition and delivery of support.
Services definition
Scope of services
It is important to very clearly and comprehensively outline the Scope of services or Scope of Work. MSPs need to take into account everything that they are going to be managing. And they should go down to the level of software or hardware pieces they will manage, number of systems to be managed, etc. If possible they should mention the devices to be managed with their model number in the annexure. The idea here is to define what the MSP is going to do, where they are going to do, how they are going to and what devices within a given infrastructure they are going to manage. Additionally, they should also mention very clearly what they are not going to manage. For example, a company might go for the support of a CRM application to the vendor that implemented the CRM. Similarly the client might have service agreements for certain hardware with the hardware vendor. MSPs SLA must consider those applications and hardware that are already under service agreements from another service provider or the manufacturer of the hardware or the developer of the application. The scope of work should clearly state that such applications are not going to be managed by the MSP.
Support hours
This section should specify the normal working hours of the service provider. It should also clearly mention the additional cost the client might incur if they need support outside the normal support hours. If the MSP does not have 24/7 operations, it must not add support outside service hours at all even if the client is ready to pay additional for such emergency services. The idea is to set the expectations right in the beginning so that people do not keep ringing you in the middle of the night.
System uptime
System uptime goals are the most common metric to highlight while writing SLAs. Usually system uptime is measured as a percentage and allows clients to review the reliability of their IT infrastructure over a period of time. Although it is very cumbersome to measure system uptime rate manually, It can be measured accurately using software especially designed for measuring system performance and uptime percentage.
Delivery of support
Delivery of support can be streamlined if the process of problem reporting, problem response time and problem resolution time are well defined and documented.
Problem reporting
Problem reporting mechanism is a must for all SLAs. The SLAs must mention the channel or the channels to be used to communicate problems. Either there can be a problem ticket application where the problem can be reported. The problems can be reported through emails to the support team. The email can be sent to the team or the dedicated support account manager. The MSPs can also be reached out through official chat or phone calls. The SLAs should mention all such possible channels. At the same time, the SLA should include the channels of communications that won’t be entertained. For example, someone sending a text message or a WhatsApp message to some member of the MSP team should not be considered to be a valid channel of communication for problem reporting. However, if the companies want to use these channels for communication, they must mention that very specifically in the SLA.
Problem response times
In SLA terminology or simply in the IT support terminology, response times refers to how quickly the MSP responds to a technical issue raised via phone, email, or other methods.
Response times can be measured as the time maximum time to respond to an email, a chat or voice message. It can also go to the level of the number of rings. When agreeing upon response times, it would be wise to explicitly clarify working hours and ensure every member in the client’s team dealing with the MSP is aware that only specific working hours are included in a response time.
For example, if a problem is reported at 9 am through an email and the email is responded at 9.10am then the response time is 10 minute. If the defined working hours of an MSP are 9 am to 5 pm monday through friday and a trouble ticket is raised at 4.55 pm on friday and responded by the MSP at 9.05 am on Monday, then also the problem response time will be considered as 10 minutes unless explicitly agreed otherwise in the SLA.
Problem resolution times
Problem resolving time is the time taken by the MSP to fully resolve a problem since it was reported or logged in. Unlike many other metrics discussed above, problem resolution time cannot be mentioned exactly in the SLA. Resolution time might vary depending on several factors and varied degrees of complexity. To handle this, each problem should be classified into different severity levels and each severity level can have an approximate resolution time.
How to make your SLAs quantitative and measurable?
Last but not least, everything in the SLAs must be measurable. At the time of review, just qualitative parameters would not be enough. Review requires numbers and numbers can be drawn only when each activity performed by the MSP can be quantified and reported. A few things such as percentage uptime can not be manually calculated. In such areas, MSPs must use software to calculate uptime percentage or downtime instances over a period of time. All the trouble tickets should be captured and each activity should be monitored from the time the problem is reported till the time it is fully resolved. There are many software that have been exclusively designed for managed service providers. A lot of these applications are available on a subscription basis. It is always advisable for the MSPs to use good quality software as they do not just allow the MSP to manage the entire engagement with each client as per specific SLAs but they also have analytics and reporting capabilities.
Termination Policy
If either of the two parties intends to terminate their contract due to whatever reasons, a termination policy in the SLA facilitates easy exit. A well-defined termination policy would take into account all possible scenarios wherein the service level agreement stands null and void. This section of the SLA also defines how the client or the MSP can initiate the process of termination. It covers how the notice needs to be served – written notice or just an email. It should mention the timelines for completing the exit including the duration of the notice period. The termination policy also highlights the MSP’s as well as the client’s liability in the event of the termination of the contract.
Conclusion
SLAs are extremely important for managed service providers. A good SLAs should clearly define obligations of the clients as well as the obligations of the service provider. The SLA protects the MSPs in many ways – at times even from complex legalities. Although SLAs are the must for every managed service provider, there are situations and circumstances where SLAs should be avoided as much as possible. A good SLA must contain service definitions such as the scope of services, support hours, system uptime percentage, etc. as well as the ways for the delivery of services including factors such as problem reporting, response time, resolution times, etc. SLAs need to be very specific and measurable, and should be reported from time to time internally to the MSP management as well as to the client who is taking the services of the MSP.
