A service level agreement (SLA) is an agreement between a cloud service provider and an organization that guarantees a minimum level of service on the provider’s part. There are three types of SLAs: customer, internal, and multi-level service level agreements.
Overtime, having an SLA for SaaS applications has become a standard within the IT outsourcing landscape. As large enterprises have outsourced more IT functions – everything from application hosting to IT help desk support – they have viewed SaaS SLA contracts as mini-insurance policies.
The idea was to “guarantee” the chosen IT service provider would deliver the promised performance levels or face penalties (like credits). The “guarantee” would allow the enterprise to focus its attention and internal resources in other value-add areas instead of focusing on IT service level management.
But IT service providers may think of an IT outsourcing SLA as something they simply have to do and must include in every master services agreement to reassure their customers. In some cases, they may not give SLAs much thought at all, using vague or generic language that doesn’t match the customers’ desired performance, outcomes and/or needs. That’s why customers have to take the reins in managing their contract details and terms to ensure their SLAs benefit them.
Why Are SLAs Important in Cloud Computing?
Today, with more firms embracing SaaS and cloud computing models in general, IT executives are particularly eager to establish clear baselines for performance. These baselines would be similar to those put in place with their IT service providers, increasing the importance of a meaningful SLA in cloud computing. SLAs and SLA software may play an important psychological role in reducing the anxiety some enterprises may feel about adopting solutions that reside in the cloud.
That’s why SLAs are often worth little more than the paper they’re printed on, especially if there is no accompanying meaningful penalty structure. Thus, prioritizing your service level agreement in cloud computing plays a key role when managing your SaaS contracts.
Clearly, meaningful SaaS SLA structures should be a part of all master subscription agreements with all chosen SaaS vendors. This includes cloud vendors like Salesforce, Workday, and ServiceNow, as well as other IT vendors like Microsoft, SAP or Oracle, that also sell cloud solutions. To make certain your SaaS SLAs are meaningful and aligned to your needs, aim to treat the following like they are SLA requirements when you negotiate your service level agreement.
Standard SLA Semantics
First and foremost, enterprises need to move beyond boilerplate and standard “shrink wrap” SLA language. Most IT vendors provide contractual documentation that is heavily “vendor-centric.” In many cases, SaaS vendors are reluctant to open up discussion and actually negotiate SLAs. More often than not, SaaS vendors will cite the difficulty in having custom SLAs and obligations for individual enterprises.
SLA Uptime Provisions
Every SLA needs to have language that provides assurances relative to uptime. When addressing uptime requirements, the measurement period needs to be carefully considered and addressed. The longer the measurement period, the more diluted the effects of the downtime.
The moment the downtime starts, the clock for calculating downtime needs to begin ticking. If vendor servers fail, end users may lose access to critical applications and data, which could severely impact the business.
Specific Penalties for Vendor Performance
A key element in SLA vendor management is establishing clear and specific penalties should the SaaS vendor fail to achieve the uptime requirements or guarantees. IT vendors will usually push for penalties of free application time (i.e., additional use). However, this is of little value to companies if they are dissatisfied with the service in the first place. This also would require the company to continue to use the SaaS solutions.
A better penalty structure should involve service credits that escalate as the length of downtime increases. It is simply not enough to have a structure with service credits; they must also be meaningful and significant. Nominal service credits for your SLA may make it more economical for the SaaS vendor to actually fail than to deliver in line with contracted terms.
The willingness to accept significant service level credits provides great insight into a SaaS vendors’ confidence in the reliability of their own system and their willingness to stand by their cloud offerings. Also, a nominal credit amount is not going to provide much relief and will not offset the damage tied to not having access to the application for an extended period — especially if it is a critical application.
Exclusion to Service Performance Penalties
Having an optimal SLA structure with defined expected targets and meaningful penalties in the form of significant service credits is not the end of your SLA strategy. Additionally, enterprises need to ensure the language does not also include significant exclusions to the right to penalties. IT vendors will undoubtedly look to include many exclusions to manage their overall risk. The more exclusions, the less meaningful the SLA structure becomes.
In addition to uptime and penalty provisions, there needs to be an escalation clause included in all contracts. Clear processes should be in place for resolving contractual issues, especially those associated with SLA adherence. Strong escalation processes around SLAs can be a critical element in establishing open communication, transparency and a healthy overall relationship with key IT vendors.
Reporting on Vendor Performance Metrics
SLA provisions should also stipulate that SaaS vendors provide monthly and/or weekly reports on key availability, continuity and performance metrics. There should be regularly scheduled SLA meetings to review this information and to strategize ways to improve SLA performance.
Every SaaS cloud subscription agreement should include a provision that allows the enterprise to terminate for serious or continuous failure to meet established service level requirements. There should be no early penalties tied to terminating for SLA non-performance and the vendor obligations upon termination need to be clearly stated.
Other Key Tasks to Consider in your SaaS Service Level Agreement
Lastly, there are a few other tasks you should keep in mind, in addition to the seven main elements just outlined, to ensure your SaaS service agreements are meaningful.
First, limit the cloud service level agreements you manage and track to those that you can align with business-impacting events. Limiting the number of SLAs you track and allocating higher percentages of your at-risk pool to penalties for those SLAs will focus and re-focus your provider’s behavior and improve your results.
You also want to make broader use of key performance indicators (KPIs). Many organizations confuse a KPI with a service level. Resolve to review your current SLA framework to identify if you are really looking to track the way a service is delivered (KPI) versus the results of the service (SLA).
Additionally, review your service levels quarterly with your internal business partners and your external service providers. What sometimes gets lost in the day-to-day management is the chance to review what you are tracking, identify short- and long-term trends, and understand the impact the services have on your business.
By committing to a quarterly review, you gain the opportunity to track these vital metrics. First, review internally with your business partners on the value of the service they are receiving and then use that to inform and empower your discussions with your vendors.
Finally, recognize good service and acknowledge it. Commit to renew your efforts to find public ways to acknowledge good service from your providers. After all, nothing is more motivating and validating to your service provider teams than to acknowledge their performance and show your appreciation.
The Bottom Line
SLAs are an important part of all SaaS cloud subscription agreements but only if the SLAs themselves are clear and the penalty structures behind them are meaningful. An enterprise’s deeply discounted SaaS subscription price can turn out to be very costly if the application does not meet the expected level of availability.