How to review support terms for Software-as-a-Service (SaaS) or Online Subscription Services
Most online subscription services or SaaS agreements include provisions regarding support, maintenance, uptime and repairs. These terms cover how often the services work, how often they might experience “downtime” or unavailability, and what to do when that occurs (who do you contact, how quickly must they respond, etc.). These terms are often in a separate document or exhibit, typically called a Service Level Agreement or SLA.
If you are the customer paying for and receiving these services, you obviously want to know that the service is going to work when you need it, and that, if there are problems, they will be remedied promptly.
Here are seven typical issues customers should consider when reviewing any proposed SLA:
- Uptime (Availability) & Downtime.
Look for an “uptime” or “availability” commitment, typically one promising service availability 99.99% of the time in any given month with a carve out for some “permitted downtime.” The two most common and reasonable carve outs for permitted downtime are (a) things outside the vendor’s control, such as internet downtime, and (b) routine maintenance.
Review these clauses carefully, as they often can be overly broad. For example, the vendor may try to excuse “emergency” maintenance. However, whenever there’s a problem, the fix is, by its very nature, “emergency maintenance,” so this is an exception that essentially swallows the rule. Emergency maintenance should not be considered permitted downtime. Also, check how routine maintenance is defined in the SLA. It should only include maintenance that meets all three of the following criteria: it must be routine, scheduled in advance, AND be done outside of normal business hours (or other peak seasons, e.g., if you’re a retailer, not on Black Friday).
- Support Hours.
If support services are critical to your business, make sure they are available 24/7/365, so you can reach someone nights and weekends if there’s an urgent issue.
- Response and Repair Times.
Response times state how quickly the vendor must respond to your report of a problem (even if just to confirm receipt of your request). These are often listed as non-binding “targets,” but, as the customer, you want them to be binding deadlines, with a remedy if missed.
Repair times (i.e., deadline for the problem to be fully solved) also tend to be stated as non-binding targets, or sometimes, are left out entirely. Customers need a firm deadline for solving problems. Vendors may explain that repair times are purposely omitted because they cannot estimate repair time until they know the root cause (a fair point). But, no matter the cause, you are paying for a service you are not getting; therefore, it is entirely reasonable for you to ask for a repair deadline, with a remedy in the form of SLA Credits (see below) if missed.
- Severity Levels.
Some SLAs have charts or tables with different response and repair times depending on the severity of the issue (from urgent/critical to minor in nature). Customers often glaze over the definitions of severity levels in these charts assuming they are all standardized, but they are not. Be sure that you agree with the vendor’s classifications. For example, the vendor may classify as “most urgent” only the complete unavailability of its service, but define “minor” issues as anytime service is partially available, with one or more features not working. However, the lack of certain service features or functionality may severely impact the customer’s business. It is therefore important that customers review this provision carefully.
- SLA Credits.
Refunds or SLA “credits” for downtime and missed repair or response deadlines are essential for customers. These credits should be meaningful, not negligible, as they are the “teeth” that motivates the vendor to keep the service running and meet its deadlines. The rest of the SLA could be airtight, but without a proper remedy, the customer lacks leverage in the event of a breach.
Credits for downtime are typically tied to how long the downtime lasts, with X% credit for availability under Y% of the time). When reviewing SLA credits, remember:
(a) Percentages should be reasonable. A 99.99% uptime “guarantee” is meaningless if you get the same remedy whether actual availability is 95% or 99%, so the remedy should increase quickly as the availability goes down by ½% or 1%. And the credits should be impactful (starting at 5-10% and working up to 50-100% of the monthly payments.
(b) Remedies should kick in right away, not only after multiple breaches.
(c) Beware of low caps on remedies. Although it is reasonable for the vendor to cap credits, caps that are too low remove all the teeth. Caps of 50-100% of monthly payments to be credited in any month even for the longest outages or repeat offenses are common and fair.
(d) SLA credits should be calculated based on the entire contract amount, not a proportional amount. Often, vendors will try to minimize SLA credits by limiting them to only the fees related to the particular portion of the service causing the problem. In other words, if a service has 100 features and only one of them is not working, you only get 1/100th of your monthly fees back. In reality, even if only one feature is not working, if it is a significant enough to disrupt the entire service, you are not getting your money’s worth.
Notice sounds like an unimportant provision, but in an SLA, it can have important consequences. An SLA might require you to notify the vendor in a very specific way (e.g., to a specific email address or phone number, or via a specific online reporting tool) before any of your rights kick in. Also, you may need to use one specific method to report a problem before the repair and response times begin (i.e., before the “clock starts ticking”), and possibly a different method to request your SLA Credits, all within a certain small time window (e.g., within 5 days) to avoid losing your rights to the credits.
For specific notice requirements for response and repair times, be sure these requirements are reasonable and that you strictly follow them to report every issue.
For specific methods and deadlines to request SLA credits, try to delete this requirement entirely. The vendor should already be tracking uptime/downtime and its own response and repair times; therefore, tracking when credits are due should be handled by the vendor and paid to you automatically. If you are unsuccessful in negotiating these away, be sure these notice requirements are reasonable and that you strictly follow them.
- Termination Right.
The right to terminate for multiple SLA violations is a pretty standard provision. However, to provide a meaningful remedy, termination rights should be defined in the SLA itself, as opposed to the main agreement.
As you may know, a typical termination provision for breach of agreement usually includes a 30-day cure period. But, in the context of service for SaaS or online subscriptions, response and repair times are measured in days, or even in hours, making a 30-day cure period under the main agreement far too long to be meaningful. A separate termination right in the SLA itself, based on frequent downtime or multiple missed deadlines, enables the customer to choose to terminate instead of getting more credits. This right could be based on the number of times a SLA is breached (e.g.. more than 3 offenses in any 3-month period) and/or for extreme downtime (e.g., availability below 90%).
No two SLAs are alike, and how much you care about each of the above issues depends on the nature of the services and how you are using them. But, as a customer, these are some of the most common issues to consider when reviewing your SLA.