SLAs, or service-level agreements, are standard features within the IT landscape. As large organizations have outsourced more IT functions – everything from enterprise software platforms to storage to help desk support – they have viewed SLAs as mini-insurance policies. The idea was to “guarantee” that vendors deliver the promised performance levels or face penalties (like reduced payments).
But vendors may think of SLAs as something they simply have to do and must include in every contract to reassure their clients. In some cases, they may not give SLAs much thought at all, just using vague or generic language that doesn’t match the clients’ needs. That’s why SLAs are often worth little more than the paper they’re printed on.
Today, with more firms embracing SaaS and cloud computing models, IT executives are particularly eager to establish clear baselines for performance. SLAs may play an important psychological role in reducing the anxiety some organizations may feel about moving key software, data and IT assets to the cloud.
Clearly, meaningful SLA structures should be in place within contractual documents with SaaS vendors. To ensure your SaaS SLAs are meaningful and aligned to your needs, consider the following ideas.
First and foremost, organizations need to move beyond vendors’ boilerplate SLA language. Most vendors provide contractual documentation that is heavily “vendor-centric.” In most 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 organizations. This is especially true for public clouds.
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 data and applications, which could severely impact the business.
Should the vendor fail to achieve the uptime requirements or guarantees, clear and specific penalties should occur. Vendors will usually push for penalties of free application time (i.e., additional use). However, there is little value for organizations if they are dissatisfied with the service in the first place.
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 significant. Nominal service credits may make it more economical for the vendor to actually fail than to deliver in line with contracted terms. Willingness to accept significant service credits provides great insight into vendors’ confidence in the reliability of their own system and their willingness to stand by their offerings.
Once an optimal SLA structure is in place, with clearly defined and non-generic targets and meaningful penalties in the form of significant service credits, organizations need to ensure the language does not also include significant exclusions to the right to penalties. 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, 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 relationships with key vendors.
SLA agreements should also stipulate that 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.
Lastly, every SaaS agreement should include a provision that allows the organization to terminate for serious or continuous failure to meet service level requirements. There should be no termination penalties and vendor obligations upon termination need to be clearly stated within the SaaS agreement.
The bottom line is that SLAs are important ingredients in effective SaaS agreements and successful IT partnerships, but only if the SLAs themselves are clear, specific and meaningful.