Introduction
Many users interested in trying out SaaS (Software as a Service) end up getting confused by all the technical jargon they come across during their research. While SaaS is increasingly becoming a popular software delivery method, many still don’t understand common terminologies associated with cloud technology. The SLA (Service Level Agreement) is perhaps one of the most important things to consider when signing up for a SaaS offering. This post aims to make it easier for beginners to understand what SLA means and what to expect from the agreement.
Since trying SaaS for free is considered the right strategy to sell an offering, it makes sense for users to grasp key concepts before making an IT investment. Let’s start with what the SLA is, how it provides a cushion against any disruption or degradation in services and the things it should include.
SaaS SLA
A service-level agreement defines what a customer should expect from the SaaS service provider and acts as a legal document. What’s important here is the fact that most service providers write the SLA keeping their own best interests in mind, which makes it very important to evaluate the agreement before finalizing it. While it’s not easy to pin down ‘cloud’ agreements, there are a few things one should consider when dealing with the SLA.
What is Included in an SLA?
A service-level agreement is more than just technology and also includes stuff such as how and when would the provider notify in case of a security breach, and data availability after the termination of the contract. An SLA essentially defines the level of service and guarantees its availability (expressed as 3, 4 or 5 nines). Less downtime usually translates into increased cost and vice versa, so one shouldn’t be surprised by higher downtimes when paying less. An agreement should ideally focus on the business value a business gets from a SaaS offering instead of totally focusing on availability.
Defining Downtime
Defining downtime is perhaps the most important element on the SLA, which should clearly define what counts as downtime. Does scheduled maintenance count as downtime? From a provider’s perspective it probably won’t, but things are different from the end user’s perspective. You obviously would not want to pay when the system is down, which makes it important to consider how the provider would compensate if something goes wrong.
Mean Time-to-respond and repair
All issues are not the same. Some require immediate attention while others can wait a bit. An SLA should clearly define the severity of issues and the mean time-to-respond and repair according to their severity. A system-down status is considered a severity-1 issue, while a module-not-working might be a severity-3 issue. You’d obviously want the provider to respond and fix the severity-1 issues before anything else, which should be defined in the SLA to avoid any inconvenience. Similarly, some users are more important than others, which means the VIP users should be given the top priority while troubleshooting issues or offering services. One would want the provider to fix the CEO’s email before moving on to ‘normal’ users.
The Escalation Path
It’s important to understand and document the escalation path i.e. who, from the management side, would be responsible to communicate with the vendor. In most cases, online support would not have full administrative access to the provider’s infrastructure. That’s why you need someone on the vendor side who can take prompt action otherwise you might end up waiting on hold without getting any real help.
Self-evaluation
One should not entirely rely on the SLA and think that they’ll get the services as promised in the agreement. A more practical approach is to keep an eye on things yourself and evaluate the service regularly. Things like service availability, service quality, and customer experience help evaluate the services in the real world. It also does not hurt to know how the provider plans to respond to in case a disaster strikes and the disaster recovery system in place.
In addition to service availability and performance, the SLA is also about how to resolve issues in the end. You might not even want to think about the SLA after you have signed it and hope that the service remains available. No one likes to fight over the spoils, but the SLA at least provides you with a covering in case something goes wrong.
Contract Language
While it’s not possible for the providers to get rid of all the legal terminologies in the SaaS SLA, they should try avoiding ‘legal speak’ just for the sake of it. Too much legal terms might result in an incomprehensible language that can even be used against the contract breaches in legal defenses. The end users should seek professional legal help if the SLA includes too many legal terminologies that an average user does not understand.
Basic SLA Structure
A service level agreement is like a mini-insurance policy in the outsourcing landscape. It’s essentially an agreement that enables businesses to focus on their core operations instead of worrying about performance levels and service availability all the time. An SLA with a generic or vague language is as good as a cookie policy we have to agree with when visiting websites.