What is an SLA?

In a lot of our contract negotiations we are dealing with the term SLA, Service Level Agreement. In the Outsourcing IT Service Industry this is a very specific term and often, in meetings it is thrown around like the terms “Cloud” or “Artificial Intelligence”. Meaning it is more of a buzz word where everyone in the meeting room has a vague understanding what it is, without really spending time on defining it. In this article I want to provide some insights, so you have a better idea of what an SLA is and how to define SLA requirements for your own business.

Service Level Agreements are Hard

A very compressed definition in IT Outsourcing for SLA. A Service Level Agreement is a commitment between a Managed IT Service Provider also known as MSP and its client to render a specific service in an agreed way.

Now, let’s slowly unpack this with a simple example. In a contract the SLA it is agreed to have IT Support onsite within 4 hours after calling the IT Support Desk during workdays between 9 to 5, if the IT Support doesn’t arrive on time, the client gets a 10% discount on the bill.

This short sentence, claims a specific service, having a qualified IT Support at the client’s site within a specific amount of time, here 4 hours, during a set range of days and times and it defines a penalty. This can get way more elaborate depending on the client’s requirements, e.g. defining details like workdays, exceptions and how things are getting measured and reviewed to make sure the service gets delivered as agreed. Yes, defining a good Service Level Agreement is hard.

Back to the meeting room

Now, let’s get back to the meeting room discussion about SLAs and what I mean with “vague”. Reality is, most of the time SLA requirements are just badly defined. We got lines likes: SLA, 2 hours.

This can come from the client directly or through another Managed IT Service Company who is approaching us for onsite IT Support in Thailand. In both ways they think they have a defined SLA requirement until someone asks what they mean by “2 hours”.

One line, many meanings

This can be, respond to a ticket in 2 hours. Be onsite in 2 hours or even have the issue fully resolved in 2 hours. All 24x7 of course.

Sometimes, there is a plain misunderstanding that an SLA is a commitment. Being able to be onsite in 2 hours is one thing, committing to be in 2 hours onsite is another thing.

A commitment means, that there are resources scheduled to respond and attend a call. This misunderstanding leads to quite interesting Service Level Agreement requirements.

An Interesting Requirement

We got asked to be onsite at their Bangkok, Thailand facility within 4 hours, 24/7 on call, which involves checking server and coordinating with an international team of engineers to troubleshoot system failures when they occur. Only the onsite time will be paid, no travel fee, 60 days common practice credit term. The hourly rate was demanded to be lower than our standard emergency rate and no agreement if we won’t to be onsite within 4 hours. And please learn and use only the client IT ticketing system. Final offer.

It started with a one liner and the client described their dream agreement. From the client side it looked great. Have a full responsive, high quality service for little to no cost in case something breaks at the datacenter. Essentially completely ignoring business economics.

You get what you pay for

From our Managed IT Service Provider side, it is a bad deal. We must have resources trained on their system, ready on call not for this client but for other clients as well. We as the service provider would have ongoing costs and can only recuperate when something happens. Having multiple of those deals worsens it, as it’s a gamble. More clients increase the likelihood something happens that gets paid. In order to make this working, we would need to hire low skilled and low-cost workers to make sure the SLA is met and hope their skill is enough and not many issues happen at once and SLAs getting missed.

Another route would be to outsource the requirement and risk to another company or freelancer who again gets paid less, since we also want to have a margin. In this scenario an international Top 500 Company pays 400 USD per hour for a high qualified external Emergency Response IT Support on paper but ends up getting an overworked freelancer for 30 USD per hour or less. Meaning you don't get what you pay for as I described in this IT outsourcing article.

How to define your SLA Requirements?

First, you need to know your IT Infrastructure and how mission critical each item is.

Second, of the actual mission critical items, how much will it cost you if it’s not operational.

Third, now you evaluate costs for a better IT Infrastructure design to mitigate failures and make occurring failures easier to handle, by being able to service failed systems during normal in-house IT hours or scheduled IT Service Provider visits.

Fourth, if IT Infrastructure improvements are not possible, then you start defining your SLA requirement for the mission critical system and any other item, meaning how fast you need someone to respond and attend to an issue. Here you start knowing how fast you need someone on site and how much it will cost you, not having someone there immediately. This way you know if you need IT Support every day, once a week and have one person or a full team on call 24/7 and how much your upper cost limit is.

Fifth, inquire Managed IT Service Provider with your Outsourcing Service Level Agreement Requirement. Know that no reputable MSP can provide you commitments without any reasonable incentives in return.

So, don’t do SLA one liners next time, unless you’re curious to see what will happen in a crisis. Need help on the 5 steps? We at Jan IT can help you getting it sorted for you. Just contact us!