This is the second installment in a 3 part series on some of the most important contractual differences in a Software as a Service (“SaaS”) Agreement. Most SaaS vendors provide there customer’s with a Service Level Agreement (“SLA”). The SLA specifies the hours of operation from the maintenance and support, it also segments the service issues and based upon the severity of the issues and more specifically there impact on the customer’s operations. SLAs typically classify service issues ranging from severity level 1-3 (some SLA offer more granularity of severity issues such as 1-5), so service issues  with a low impact (level 1), medium impact (level 2) and a high impact (level 3) on the customer’s operation. Then the SLA establishes the average metric for responding to each such service  classification; i.e. level 1 issue, states an average time to fix that Level 1 issue; and the average time to fix the defect. Of course to make an SLA viable it also needs to provide the customer reporting on the SLA uptime performance metrics.

If this were simply a service, the SLA would be a terrific and meaningful substitute for remedy, after all these metrics are stating in detail how long it with take on average to respond and cure a performance defect, this level of detail goes well beyond average maintenance agreement or general service obligations, and after all isn’t that what a warranty does, i.e., cure service performance defects? The challenge with that approach is that in addition to the classical service, the SaaS offering also includes a term license (a license right to operate the application software for a limited period of time, typically an annual fee). If you read least month’s paper on SaaS Acceptance, you will remember most often SaaS vendors do not offer customers (subscribers) a classical acceptance period in which they can verify that the software works in accordance with the software documentation; this makes the inclusion of a meaningful warranty even more important, as it is the only contractual assurance that the Service actually works in accordance with the documentation . Under these circumstances you would expect that most SaaS Agreements would offer a robust warranty, but in practice it is quite the opposite, most SaaS Agreements simply offer an SLA; and most SLAs do not offer a refund option if the SLA metric is not met.

What makes that even more difficult for the SaaS customer to accept is that most SaaS agreements are offered under a  pre-paid non-refundable annual fee. So you pay in advance, and must rely upon an SLA to ensure that the Service works properly through the term of that SaaS license. If a SaaS vendor fails to cure Service issues within the stated time frame or fails to provide the promised percentage of uptime; e.g. 99.8% then the customer is typically provided with a service credit. What is generally not offered, but extremely important to request is that, in the event the SaaS Vendor fails to meet the metric in 3 consecutive months, or in 3 out of any 6 consecutive months, then the customer should have a right to terminate and receive a pro-rata refund of the SaaS fees from the time the uncured Service failed. This is appropriate because 1) SaaS Agreements typically do not offer a classical Acceptance; and 2) nor do most SaaS Agreements offer a classical warranty term. Under this scenario this SLA is the customer’s only recourse if the Service does not perform as per the documentation, so if the SaaS vendor cannot cure the defect, the customer needs the option to terminate. In many SaaS Agreements, there is no Acceptance Term, and there is no warranty term, so the standard set of SLA remedies needs to also include a refund if the SaaS vendor cannot make the Service perform to the specification after several SLA opportunities to cure.