As customers continue to embrace Software as a Service (SAAS) solutions that are hosted in the cloud, rather than traditional software solutions that are loaded onto and hosted on the customer’s own environment, they should closely review the contract that will govern their relationship with their SAAS provider. Frequently, we see SAAS contracts that are missing certain basic (and key) requirements that serve to protect SAAS customers.
In the first of a two-part series, we offer the following critical contract protections that SAAS customers should keep in mind, before signing any SAAS agreement. Alternatively, if a customer already has a SAAS agreement that omits any of the following terms, the customer should explore amending its current agreement to include these protections, during its next contract renegotiation.
Implementation Schedule If a SAAS solution is being put into service for the first time for a customer, the customer should make sure that the contract lists the expected schedule for the implementation, including the milestones that must be met and hard dates (not wishy-washy “we hope to get it done” or “we will use reasonable efforts to try and get it done” by a certain date) by which the milestones must be met. If the milestones are not attached to hard dates, then arguably, an implementation that is over one year behind schedule may be “late” in terms of what everyone expected, but it may not be late in terms of the specific guarantees in the contract.
Milestone Payments Related to implementation concerns, if there is an “upfront” payment expected or if there will be implementation fees associated with the set-up and implementation of the SAAS solution, many customers prefer to tie that payment to successful completion of the milestones, rather than simply pay the entire amount up-front. A related protection is that “successful completion” of the milestone should require that the customer provide written sign-off that the milestone has been successfully completed, rather than (simply) the SAAS provider’s notification to the customer that the milestone has been completed.
What Does the Final “S” in “SAAS” Actually Mean? If a customer is contracting for “Software as a Service”, the customer must make sure that its contract has clear, well-defined descriptions of the specific “Service” or “Services” that it will receive. Many SAAS contracts include detailed provisions with respect to payments due from the customer, as well as general legal provisions, but very little description of the service or services that the customer will receive. Related to this point, SAAS customers should make sure that their contract includes appropriate guarantees that the SAAS solution will comply with any requirements, specifications, on-line documentation and/or manuals that describe the services.
When Is Support Available? SAAS customers should make sure that their contract describes the hours during which the customer may receive support from the SAAS provider. Is the customer paying for 24×7 support? Or is it paying for support only during business hours? Be mindful of time zones if support will received only during certain hours – what if the customer is in California but the service/support center is in Florida? (or Ireland? or Poland?) If the customer elects to pay for support only from 8:00am – 5:30pm ET, is after-hours support available for an additional cost? Does the contract list that charge?
Clear Understanding of Maintenance Windows SAAS solutions are hosted on servers and/or equipment that is outside the control of the customer (whether the customer is accessing that SAAS solution over the Internet, a private network, or otherwise). When a customer gives up control of the hosting of the SAAS solution, the customer needs to clearly understand (1) when the normal maintenance windows will occur for the SAAS solution, (2) the extent to which the SAAS solution can or cannot be accessed during those normal maintenance windows, and (3) what the SAAS provider’s rights are (and any related procedures) with respect to shutting down the solution outside of the normal maintenance windows? If a critical issue arises outside of the maintenance windows, does the SAAS provider have the right to shut the solution down? Will the provider notify (or attempt to notify) the customer, before shutting down the SAAS solution?
Uptime Service Levels with Teeth Related to the Maintenance Windows, customers should make sure that their SAAS agreement includes clear service levels with respect to the uptime of the solution (for example, 99.9% uptime monthly), and ensure that the service level “has teeth”. The “teeth” means a service level credit that is paid to the customer, if the guaranteed service level is not met within a given period of time (usually monthly). Without “teeth”, a service level is really nothing more than a hopeful target. SAAS providers should stand behind their contractual service levels and provide an appropriate payment amount back to the customer (usually a percentage of monthly fees), if the service level is not met. Some suppliers will refund a proportionate amount of the monthly fees compared to the minutes lost in excess of the service level. Given the number of minutes in a month, that is typically an insignificant amount that doesn’t motivate the supplier to fix the underlying problem that caused the failure in service.
And Just How Does the SAAS Provider Calculate “Uptime”? Related to the uptime service level review, SAAS customers should closely examine the language that describes how the uptime service level percentage is calculated. If the maintenance window runs from 1:00am – 5:30am each Sunday night, and if the customer has been told that it should not expect to be able to access the SAAS solution during those hours, then the SAAS provider should not receive “uptime credit” if it happens to have the SAAS solution back up-and-running by 4:30am. The “uptime” calculation should examine whether the SAAS solution is available during the times that the customer expects to access the solution (and those time windows should be clearly listed in the contract). The calculated uptime should not include any time that overlaps with the contractual maintenance windows. Additionally, closely examine the language with respect to “emergency” maintenance. A customer may be okay with contract language allowing the SAAS provider the right to take the SAAS solution down to perform emergency maintenance in the middle of a work day. However, the resulting downtime should count against the “uptime” calculation. Some SAAS providers have been known to insert contract language that excuses any such emergency maintenance from being calculated as “downtime”, by simply sending an email prior to taking the solution off-line. Be careful of this: emergency downtime may be operationally necessary but “downtime” is still “downtime”.
We will continue this list in Part 2.
The topics explored above are addressed at a high-level and not particularly nuanced, but SAAS customers should raise these issues with their supplier and their legal advisor so that the necessary provisions and contract language can be inserted into their SAAS agreement to appropriately protect their business.