A Service Level Agreement (SLA) forms a part of your IT contract. It defines what your provider actually commits to and how fast. Most business owners have one buried in their agreement and have never really read it.
Today I’ll break down what a real SLA should define and gives you a check you can run on your own agreement today to see if yours actually protect you.
Does yours actually protect you? What a real SLA should define:
- Severity levels (not every issue is equally urgent)
- Response time vs. resolution time (acknowledging an issue isn’t the same as fixing it)
- What happens if they miss a commitment
- Explicit exclusions
If your SLA doesn’t clearly define severity levels, response vs. resolution time, what happens if a commitment is missed, and what’s excluded, you’re relying on goodwill — not an actual agreement.
What is an SLA?
A service level agreement is the part of your contract that defines what the provider commits to doing and how quickly. It’s basically the bit of the contract that separates the marketing speak from the real-world results.
For example, every company uses marketing to a certain extent and marketing use words like ‘fast’ or ‘reliable’. But what on earth do ‘fast’ or ‘reliable’ actually mean? The purpose of the SLA is to take those words and turn them into something that is a little bit more measurable, a little bit more specific. An SLA should clearly define four things.
#1 – Severity
I think we can all agree that not every issue is equally urgent. For example, your network being completely down with nobody able to do any work is far more urgent than one person in HR who can’t access a file. To address this, most IT providers work on a priority basis.
Most providers use a sliding scale that goes from a P1 down to a P4, with P1 being the most urgent and P4 being the least. A priority one ticket would be a critical outage, something that’s affecting your entire business. A P2 would be a high impact issue, affecting a lot of users, perhaps even an entire site or branch. P3 is medium impact, so a general issue affecting two or more users is inconvenient rather than catastrophic. A P4, on the other hand, would be low impact, like a minor bug or a single user experiencing an issue. With each priority level, you should expect a different response and resolution from your service provider.
One thing to be aware of is that over classifying faults, such as raising everything as a P1, is crying wolf, and in that case you may not get the service you require when you really need it.
#2 – Response Vs. resolution time
I mentioned marketing words before, and of course, response and resolution both sound great. They sound like you’re actually getting your issue fixed, but they’re very different.
Response means your issue has been acknowledged, while resolution means it has been fixed.
Most IT providers focus on promoting response time because it’s often much shorter than resolution time. The most common issue businesses have with an SLA is that they focus so heavily on the marketed quick response time that they ignore the longer, often vaguer resolution time. At the end of the day, a 15-minute acknowledgement means little, if anything, if your fix has no target time. So make sure you factor both in.
Also, it pays to be clear on what response time actually is, because the word response can mean different things to different people. For example, if you called an ambulance, a response time could mean how quickly they’re answering the phone, but you might assume that that means that’s how soon you’re going to have an ambulance on site. It’s worth making sure both parties agree on the terminology being used, because the last thing you want is a P1 outage where you’re expecting your provider to drop everything and investigate your issue. Where from your provider’s perspective, they’ve met their goal simply by answering the phone and giving you a ticket reference.
#3 – Consequences
What happens if your provider misses their target? You have a written SLA with aresolution time of 4 hours, and 5 hours later you’re still suffering. What’s the impact to the provider? For you, your business is losing money. For the provider, they could just be ticking along and have all the time in the world.
You need a way to ensure that there is some impact to their business, which, let’s face it, 9/10, this is going to need to be a financial impact. Usually, this is handled through service credits.
A service credit is basically taking a percentage of your monthly fee, scaled to the severity of the fault.
And at the end of the day, a commitment without any kind of consequence for missing that target is really not a commitment. It’s more of a hope.
It’s also worth, on that point, actually insisting on some form of regular performance report that will show you their performance against the target. That way, if they miss their target, it’s easy to identify it without having to argue the issue after the fact.
#4 – Exclusions
It’s important that you know any exceptions. More often than not, this will be third-party outages, ISPs, acts of God, but it’s important to understand what isn’t covered so you can assess the impact on your business if they fail. For example, if you rely on your IT provider for internet access but they exclude their ISP, and their ISP has a fault, you could have literally no internet access.
The good news for them is that they don’t have to pay you any service credit. The bad news for you, of course, is that you have no internet, which means that you may not even be able to trade.
If you’ve made it this far, let’s do a real-world SLA check.
Does your SLA include the following?
- Does it distinguish between severity levels?
- Does each level have a separate response and resolution time?
- Does it say what happens if the SLA target is missed?
- Does it list any exclusions?
If you don’t have or you can’t find an SLA, or yours feels a little bit vague on one or all four of these points, that’s not automatically a disaster, but it does mean that you’re probably relying a little bit too much on goodwill. So, it’s probably worth spending some time raising this with your IT provider at your next service review.
