How to make your SLAs meaningful in SaaS cloud subscription agreements

To make certain your SaaS SLAs are meaningful and aligned to your needs, ensure you have considered the following seven aspects of any agreement.

Read the fine print contract agreement
Thinkstock

SLAs, or service-level agreements, are standard within the IT outsourcing landscape. As large enterprises have outsourced more IT functions – everything from application hosting, to application maintenance and support to IT help desk support – they have viewed SLAs 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. 

But IT service providers may think of SLAs 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 SLAs are often worth little more than the paper they’re printed on, especially if there is no accompanying meaningful penalty structure.

Today, with more firms embracing Software-as-a-Service (SaaS) and cloud computing models in general, IT executives are particularly eager to establish clear baselines for performance similar to those put in place with their IT service providers. SLAs may play an important psychological role in reducing the anxiety some enterprises may feel about adopting solutions that reside in the Cloud.

Clearly, meaningful 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, ensure you have considered:

  • SLA semantics
  • Uptime
  • Penalties
  • Exclusions
  • Escalation
  • Reporting
  • Termination

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.

Uptime

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 needs to begin ticking in terms of calculating downtime. If vendor servers fail, end users may lose access to critical applications and data, which could severely impact the business.

Penalties

Should the SaaS vendor fail to achieve the uptime requirements or guarantees, clear and specific penalties should be defined and should occur. IT vendors will usually push for penalties of free application time (i.e., additional use). However, this is of little value to enterprises if they are dissatisfied with the service in the first place.  This also would require the enterprise to continue to use the SaaS solution.

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 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 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 certainly not offset the damage tied to not having access to the application for an extended period of time -- especially if it is a critical application. 

Exclusions

Once an optimal SLA structure is in place, with clearly defined expected targets and meaningful penalties in the form of significant service credits, 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.

Escalation

In addition, there needs to be an escalation clause included within 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

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.

Termination

Lastly, 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.

The bottom line is that 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.

Other steps you can take to improve your service level management:

  • Limit the service level agreements (SLAs) 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 that, if missed, would impact your business, will focus and re-focus your provider’s behavior and improve your results.
  • Make broader use of KPIs. Many organizations confuse a key performance indicator (KPI) with a service level. Review your current SLA framework to identify what you are tracking, to identify if you are really looking to track the way a service is delivered (KPI) versus the results of the service (SLA).
  • 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 trends year-over-year and month-to-month, and take the opportunity to understand the impact the services have on your business.
  • Recognize good service and acknowledge it. Commit to renew your efforts to find public ways to acknowledge good service from your providers.

This article is published as part of the IDG Contributor Network. Want to Join?

NEW! Download the Spring 2018 digital edition of CIO magazine