When a customer purchases software-as-a-service (SaaS)–which is sometimes called a “cloud” service or product–the software is not hosted. It does not reside at the customer’s location or data center. Rather the software is hosted by the vendor internally or at a third-party data center such as AWS, Azure, etc. The customer connects to the software over the Internet and accesses its functionality remotely. Typically, all the underlying infrastructure to make the software work (servers, related software, environmental controls, power, connection to the Internet, etc.) are procured, managed, controlled and maintained by the vendor, not the customer.
When a customer gives up control of this underlying infrastructure, it also gives up control of the components that ensure the software can be consistently accessed and used when needed. SaaS/Cloud software vendors generally offer a Service Level Agreement (SLA) to their customers, under which the vendor commits that the SaaS/Cloud software will be “available” to the customer for a certain percentage of time (e.g., 99%, 99.9%, 99.99%, etc.). At first glance, these percentages appear very high and seem to require that the vendor ensures the software can be accessed and used by the customer just about 100% of the time. Unfortunately, a thorough legal review of a SaaS/Cloud software contract must go well beyond the stated availability percentage. There are hidden techniques vendors commonly employ within their SLAs which, if not rectified, can seriously erode the vendor’s availability commitment. Here are three things often found in–or missing from–SaaS/Cloud software vendor SLAs that dilute the availability commitment.
Thing #1 – Credits Offered as Sole and Exclusive Remedies: Often, a vendor SLA will provide that, if an SLA commitment is missed, the vendor will provide the customer a small credit, sometimes expressed as a small percentage of the monthly fee or a fixed amount which is only a small percentage of the monthly fee on its next invoice. Somewhere else in the SLA, the vendor then states that the remedies provided in the SLA (the credit is typically the only remedy stated) are the customer’s “sole and exclusive remedy” for vendor’s failure to provide the SaaS/Cloud software service in accordance with the SLA.
While an SLA may appear to be contractual protection for a customer trying to ensure that the SaaS/Cloud software is provided consistently (i.e., virtually all the time), when it includes “sole and exclusive remedy” language, it is actually a protection for the vendor, not the customer. The “sole and exclusive remedy” language ensures that, no matter how badly the vendor fails in its promise to deliver its own product on its own infrastructure to the customer, the vendor cannot be sued by the customer for such failure, the contract cannot be terminated for such failure, and all the customer can do is grudgingly accept a very small credit, without any commitment that the SaaS/Cloud software will be delivered within the SLA in the future. To add insult to injury, the small SLA credits are generally within the vendor’s profit margin, so the net effect is that the vendor is still making a profit (albeit smaller than expected) on SaaS/Cloud software provided to a customer below the SLA availability percentage. A SaaS/Cloud software vendor’s failure to deliver that software within the SLA terms often has serious adverse impacts on the customer’s operations and one of the most powerful tools a customer has is the threat of contract termination. The customer voluntarily gives away this tool when agreeing to SLA credits as the sole and exclusive remedy.
Thing #2 – SaaS/Cloud Software Measurement and Maintenance/Emergency Windows: Any SLA that states the SaaS/Cloud software will be provided a certain percentage of the time, e.g., 99.9% of the time, must also state the period over which the SLA is measured. Again, while 99.9% of the time may seem very high, if measured over a 1-year period, 99.9% of the time would leave 3 days, 15 hours and 36 minutes of unanticipated downtime. 99.9% of the time measured over a 30-day month would still result in 7 hours and 12 minutes downtime. Often, vendor SLAs also exclude “maintenance windows” and “emergency maintenance” from the SLA calculation, without stating (at least in the SLA) what the “maintenance windows” or “emergency maintenance” events are. If, for example, the vendor’s maintenance windows are on weekends and holidays, which may seem innocuous, not only does this mean that there is no SLA at all on weekends or holidays, it means that 100% of the permitted downtime noted above (3 days, 15 hours and 36 minutes if measured yearly, or 7 hours and 12 minutes downtime if measured monthly) can be consolidated into regular business days, when it would more likely be an issue for the business users. Furthermore, excluding “emergency windows” from the SLA calculation is similarly problematic. A vendor should not be able to simply declare an “emergency” anytime it wants, thereby removing any SLA commitment. The reason a 99.9% SLA is not 100% is precisely to account for unexpected emergencies. Adding an additional exclusion for an “emergency” that a vendor happens to declare is a perverse incentive at best, and at worst could result in the SaaS/Cloud software not having a meaningful SLA at all.
Thing #3 – SaaS/Cloud Software Functionality: Even if a customer can access SaaS/Cloud software 100% of the time, the software will not help the customer meet its business need if it does not have all the functionality the customer expects. Typically, a SaaS/Cloud software contract will include a representation and warranty that the software will possess the features and functionality described in its documentation. Unfortunately, this commitment is rarely, if ever, tied to the SLA. Many vendors consider that their SaaS/Cloud software is “available” in accordance with its SLA if the customer can connect to the SaaS/Cloud software even if, when connected, the SaaS/Cloud software does not contain all the functionality described in the documentation. The SLA should make very clear that the software is considered “available” to the customer only when it provides all functionality described in its documentation.
SLAs in SaaS/Cloud contracts can be challenging to negotiate, but legal advisors and IT users should be particularly diligent in their negotiations of these terms. Maybe more than any other part of a SaaS/Cloud software contract, SLAs have a profound impact on whether a customer is satisfied with a software product and informs how responsive a vendor will be if those expectations are not met.
Marc D. Lawlor is a partner at Conn Kavanaugh in the Technology & Outsourcing Group.
He can be reached at mlawlor@connkavanaugh.com
Share with your network:
