Have you ever failed to buy a good IT service because of signing a contract with a bad SLA? If you bought an IT service and had to live with it, you know how important the SLA is. Terms, which don’t meet your company’s expectations can ruin the user experience. When the users are dissatisfied with IT services, your reputation as an IT manager suffers. Check out our 10 SLA best practices to consider when you choose your cloud computing vendor.
What’s SLA?
SLA is an abbreviation of Service Level Agreement. When buying an IT service you sign a contract. It contains all the terms and conditions the vendor has to meet while providing the service. SLA is a part of the contract when you can find parameters defining the quality of the service. In other words, SLA tells you how well the vendor commits to providing the service for you.
By the definition alone you can tell how important it is to negotiate SLA which satisfies your needs. With insufficient parameters of an SLA, you’ll be stuck in poor service for many months. Especially if your contract terms make it unprofitable to stop it before its end.
When to ask your vendor for the draft of the SLA?
You should ask all the considered vendors as soon as you start talking with them. By waiting until you’re sure that you want to choose this particular vendor, you take yourself hostage.
It’s called a sunk cost fallacy and is one of many cognitive biases people are vulnerable to. You spend much time analyzing a set of services only by its features. Finally, you pick the one you like the most. Then you start to analyze its SLA. While evaluating it you remember all the effort you put into selecting the service you like the most. You don’t want this time to become wasted. That’s why you’ll be more agreeable to the SLA which doesn’t fully meet your needs.
You can evaluate SLA right from the beginning as one of the aspects of the service. This approach will guarantee a more objective perspective. You will choose the best service as a whole, which does not always mean only the best features.
As we’ve covered that, let’s get to the 10 steps of the fail-proof approach to sign a better SLA.
SLA best practice 1 – Verify what the declared availability really means.
Providers define availability as a percentage of time the service is available in a given period of time. You’ll see numbers like 99% or 99,9%. It seems quite straightforward. You should ask though what period of time this number refers to. The 99% of availability may refer to a month. It means that you’re exposed to the risk of 8 hours without the service every month. It may also refer to a year. In this case, you risk not having access to a service for 3,5 days.
There’s a little chance that a single outage would last that long. It may happen though, and there may be no other disruptions of the service in the same period. If it happens, the contract is met, so you can’t request the vendor to compensate for any of your potential losses. Losses, which may be significant for you…
Another thing you wish to clarify is if the availability commitment applies to the 24/7 time basis. This is a standard of the cloud computing sector. If the vendor guarantees to provide the service with 99,99%, but only for 12 hours per day, you should turn on all your red lights. Unless he has a good for offering this kind of SLA, he may not be honest with his offer.
SLA best practice 2 – Check out the terms of scheduled outages.
Availability most often doesn’t apply to scheduled outages. Check if the vendor reserves extra time for scheduled outages. He will need them for maintenance work, upgrades, and implementations of new features.
If you If you agree to the scheduled outages terms, be sure about all the circumstances of them. Verify the part of week and day they may appear. Check the timezone in which the vendor gives himself time windows for maintenance. Many of the service’s customers can be located on a different continent. The vendor will more likely please them than you if they are in the majority. In this case, you’ll end up with recurring scheduled outages disturbing your business during your business hours.
SLA best practice 3 – Beware the transfer of responsibility.
Some providers try to transfer the responsibility of their subcontractors’ work. They want to put it on your shoulders rather than theirs. It happens when a vendor doesn’t take responsibility for the outages caused by their providers. They can do it by adding one sentence to the SLA. For example, they can write:
“Availability guarantee doesn’t apply to the situation caused by other parties.”
or
“Availability guarantee is limited only to the situation caused by the Provider.”
You may find it written in an even more cloaked way in a contract. In this case, always ask the vendor what he means by that.
You shouldn’t agree on transferring the responsibility to you. You have no influence in choosing the provider’s subcontractors, after all. Your vendor should declare the availability guarantee which addresses all the risks. If you have reasons to accept this kind of condition, be very careful with it.
SLA best practice 4 – Verify how your issues can be reported.
When you have any problems with the service, you’ll report it to the vendor. Check the ways of reporting the issue accepted by the provider. He can offer reporting in the ticket system only. In this case, you may have to submit a ticket before you talk with anyone from the support team. Not all vendors are so strict about it. It’s good to ask them about it. Of course, the sales guys can assure you of the flexibility of these procedures. If quick, direct access to the support team is a priority for you, you’ll want to request a free trial of the service. It would give you a chance to verify the real quality of the service.
Generally, the more channels the vendor offers to report issues the better. The best possible case is when the provider offers reporting by telephone, e-mail, chat, and the ticket system. Regardless of the way the issues are reported, they should be documented. The vendor’s team should submit a ticket on the user’s behalf for every issue reported without the ticket. Both – you and the provider will need it to evaluate and settle the service.
For some reason, you may prefer to limit the number of ways of submitting tickets. You can also want some particular way to be accepted. Check in the proposed SLA if the vendor offers this type of customization.
SLA best practice 5 – Check the time of ticket response and solution time.
The vendor should declare very clearly the conditions on which the ticket’s priority is assigned. After signing the contract you should be absolutely sure which priority assign to any given ticket. There are different ways to achieve it. You can have your own best practice.
In our organization we usually try to convince vendors to agree on the following classification:
- Critical priority – if at least one of the major modules of the software doesn’t work at all. Another reason to classify tickets as critical is one of the features specified by the client. We specify these features or processes very clearly.
- Low priority – if the vendor has provided a workaround for the issue.
- Medium priority – all the other tickets.
If you have your own best practices for ticket prioritization and you wish to share them, please do it in the comments below.
If a lot of users will be operating the service you may also differentiate the priority based on the number of affected users. Of course, the more users are affected, the higher the priority gets.
SLA best practice 6 – Double check the time of ticket response and solution time.
You want the ticket response time and the issue solution time to fit your business needs. This is the most important aspect of your SLA in the area of the service’s support.
The vendor has to put much effort to meet the agreement if he declares short response and solution times. He considers not meeting these declarations as one of the biggest risks in the contract. That’s why you can have a hard time negotiating satisfying values.
Even if you’re not fully satisfied with the response time and the solution time, be sure that you communicate the final agreement to your users. When they report issues, they have to know when to expect the response and the solution from the support team.
You should also verify the dependency between the response time and the solution time. Vendors often define the start of the solution time as the moment of the first response. But what if they never respond? In this scenario, when the agreed response time passes, the solution time should start to run automatically. It seems obvious, but be sure that it’s written down in your SLA.
SLA best practice 7 – Ensure safe business terms and legal protection.
In your organization, you probably have different kinds of data. Each of the data types needs a specific level of privacy and security. Before you analyze your SLA it’s good to have them identified. While verifying the SLA you want to decide which types of data you’ll process in the service. Having that, you check if the vendor meets your requirements for each type of data. Some things to check are:
- For some reason, your data may have to stay in the same country or region as your location. In this case, verify the locations of all data centers the vendor serves his applications from. Ask not only about the main data center but also about the spare one and the one they have to keep backups in.
- You may want to ask about the procedures and technical ways of handling personal data. Regulations like the infamous GDPR in the EU are now implemented in many countries. Check where your users may come from. Ensure that the service provider will treat their personal data accordingly.
You should always work on SLA with your lawyers. It will allow you to cover all the business terms that are necessary according to law. They will help you with other things you have to include in the contract too. You most often don’t know all the aspects necessary from the business point of view.
The lawyers will also tell you what you have to include in the SLA to secure the agreed terms. Having the best availability and solution terms won’t help you if you won’t have the tools to enforce it. Fortunately, most of the vendors in today’s market value their reputation highly. They won’t risk under-delivery for no reason. But even the best provider will consider lowering his standards if he gets into trouble. Try to negotiate the conditions that will make him lossier on failing on your contract than on other options.
SLA best practice 8 – Verify if the vendor can deliver the promised level of service? How he did it before?
You include your legal protection terms in the SLA in case the vendor does not fulfill his obligations. But you don’t buy the service to charge the vendor a penalty fee or litigate in court. You buy it cause you want the service to be provided as you need it. There is another way to have another layer to verify if the service delivery will be seamless. You can ask the vendor for statistics showing how he did before. He may not show you individual tickets for privacy reasons. He should be able, though, to show you the overall statistics of availability and ticket metrics. Some of the information you may ask for are:
- The availability of the service in the past 12 / 24 months.
- Number and duration of unplanned outages for in past 12 /24 months.
- Rate of the support tickets not meeting the SLA.
- Average time of responding for a support ticket.
- Average time of resolution of a support ticket.
If he refuses to share this information, it’s probably a sign that he’s not as good as he promises.
SLA best practice 9 – Check again if the vendor can deliver the promised level of service? How he plans to achieve it?
Does the vendor promise you 99,9% of availability? You may ask him how he does that. For example, if he runs the application in a highly available environment?
Does the provider ensure you about the 24/7 helpdesk support? You’d like to ask him how many people work in his helpdesk team. Why ask this question? Your provider may provide the 24/7 service by overloaded employees working way too many hours. The terms theoretically will be met, but you won’t be happy with the service provided that way. Proper service support is crucial for the user experience. Even if the service is very reliable, you’ll have to contact support from time to time. Tired and unhelpful helpdesk specialists may ruin how your users evaluate the service.
These questions may seem to you too intrusive. Think of it this way. If a vendor put much effort and resources to provide the best service, he’ll surely want to tell you about it.
SLA best practice 10 – Check how big can you grow with this service.
If you expect your organization to grow significantly in the future, this is the aspect you should deeply consider. You may ask your vendor to add the scalability assurance in the SLA.
A good way of verifying that is by asking the vendor how many users the service has. You can also ask about the user count of its biggest customer. You don’t want these numbers to be lower than your expected, or even worse, current size.
The first thing constraining growth could be the infrastructure the service is provided on. Your vendor will probably use a subcontractor’s virtual infrastructure. Ask what is the subcontractor and how the subcontractor assures the scalability.
But even if the service runs in the best data centers in the world, there’s always a middleware and the application itself. As the service will grow, they will cause trouble, which the vendor doesn’t expect. This is why you don’t want to be the biggest client. You don’t want the provider to test the software scalability on you.
Conclusion
Studying and verifying the SLA isn’t the most exciting thing you can do. But you don’t choose the service just for today. Most probably you’ll use it for years. If you do it properly, your effort will pay off many times during these years. Unfortunately, there are no shortcuts to it. Do your homework and go through these steps:
- Prepare your expectations and requirements.
- Confront them with the terms, that the vendor proposes.
- If some aspects don’t meet your requirements, negotiate them.
- If you can’t negotiate anymore, choose another vendor.
Of course, it’s much easier said than done. Choosing the best service will often force you to compromise on a few things. Even if you choose a service, which doesn’t satisfy all your needs, it’s better to know all the drawbacks before signing the contract. Eventually, if there’s nothing worth buying on the market, you can decide to build the service yourself.
No matter what you choose, analyze your options carefully and choose your solution consciously.
