Service Levels

One of the most critical aspects in drafting and negotiating a cloud computing agreement is establishing appropriate service levels in relation to the availability and responsiveness of the software. Because the software is hosted by the vendor without the customer’s control, service levels serve two primary purposes. First, service levels assure the customer that it can rely on the software in its business and provide appropriate remedies if the vendor fails to meet the agreed service levels.

Second, service levels provide agreed-upon benchmarks that facilitate the vendor’s continuous quality improvement process and provide incentives that encourage the vendor’s diligence with respect to addressing issues. In cloud computing contracts, customers should generally focus on uptime, response time, and problem resolution.

Uptime Service Level

Because the software your company is using is hosted by the vendor, the vendor needs to provide a stable environment in which the software is available to the customer when required, if not twenty-four hours per day, seven days per week. An uptime service level will address this issue by having the vendor agree that the software will have an uptime (i.e., availability) of a certain percentage, during certain hours, measured over an agreed-upon period. By way of illustration, here is an example of this type of provision:

Vendor will make the software Available continuously, as measured over the course of each calendar month period, an average of 99-99 percent of the time, excluding unavailability as a result of Exceptions, as defined below (the “Availability Percentage”). “Available” means the software shall be available for access and use by Customer. For purposes of calculating the Availability Percentage, the following are “Exceptions” to the service level requirement and the software shall not be considered unavailable if any such unavailability is due to: (i) Customer’s acts or omissions; (ii) Customer’s Internet connectivity; or (iii) Vendor’s regularly scheduled downtime (which shall occur weekly, Sundays, from 2:00 a.m. to 4:00 a.m. Eastern time).

While the specific service level targets (e.g., percentage availability requirement, measurement period, exceptions to availability) depend on the facts and circumstances in each case, an uptime service level (and some form of the example above) is common in cloud transactions. Customers should not simply accept the default vendor positions on uptime percentages, measurement periods, and exceptions, but should instead negotiate terms that address the customer’s business needs and requirements and are appropriate for the type, complexity, and importance of the software being used.

Moreover, customers should carefully consider the permitted outage measurement window (e.g., daily, monthly, and quarterly). Vendors tend to want longer measurement periods because they dilute the effects of a downtime and make remedies less available to the customer. Customers should receive written documentation of a vendor’s scheduled downtime and ensure the window creates no issues for the customer’s business (e.g., is not scheduled during a time period where the customer expects usage of the software). Customers may also request that the vendor be proactive in detecting downtime by explicitly requiring the vendor to constantly monitor the “heartbeat” of all its servers through automated

“pinging.” Requiring the vendor to do this should result in the vendor knowing very quickly that a server is down without having to wait for a notice from the customer. Finally, the concept of “unavailability” should also include severe performance degradation and inoperability of any software feature. This is discussed in more detail in the next section.

Beware of three recent vendor trends in service level calculations. First, they change the measurement period of monthly to quarterly—thus providing only three opportunities per year to obtain credits and exercise other rights for failure to achieve required service levels. Second, vendors include language stating that an episode of unavailability must persist for at least ten minutes to be counted toward service level performance. Uris means the vendor can be down an unlimited number of times for nine minutes and fifty-nine seconds every day and the customer will receive no service level credit or other remedies. Finally, vendors are changing how “availability” is defined so that 100% of the functionality of the platform or application may be unavailable, but if their system responds to a basic ping, as described in the preceding paragraph, they will not be considered unavailable. This would greatly undermine the value of any service level.

Response Time Service Level

Closely related to and often intertwined with an uptime service level is a response time service level. This service level sets forth maximum latencies and response times that a customer should encounter when using the software. Remote software that fails to provide timely responses to its users is effectively unavailable. As with the uptime service level, the specific service level target depends on the facts and circumstances in each case, including the complexity of the transaction at issue and the processing required. Note that response time service levels are typically included with the definition of “availability” set forth in the uptime service level section. Here is an example provision of a response time warranty:

Vendor guarantees that 98 percent of software transactions will exhibit two seconds or less response time, defined as the interval from the time the user sends a transaction to the time a visual confirmation of transaction completion is received.

Problem Resolution Service Level

In addition to the appropriate service levels, a vendor must be obligated to resolve issues in a timely manner. Vendors often include only a response time measurement, meaning the time period from when the problem is reported to when the vendor begins working to address the issue. These obligations typically fall short of what is necessary since they only include a response without any commitment to actually correct the problem. As a result, the service level should include both an escalation matrix (defining the level of severity of the problem and response times for each level) and specific vendor obligations to address and correct the problem or provide an acceptable workaround.

Remedies for Service Level Failure

Remedies should cover both a failure to hit a service level and a failure to timely resolve a reported support issue. Typically, these remedies start out as credits toward the next period’s service. For example, a remedy might provide: for every percentage of downtime below the agreed-upon level in the measurement period, or for every severity level 1 support issue vendor does not resolve within the stipulated time, the customer will receive a 5% discount on the next month’s bill, up to a maximum credit of 100%. Another format that is commonly used is the following: If the availability service level is 99-99% in each month, customer will receive a $500 credit in each month where the availability is between 98% and 99-98%, and a $1,000 credit if the service level falls below 98%. The remedies should scale such that if repeated failure occurs, the customer should have the right to terminate the agreement without penalty or having to wait for the current term to expire. Here is a portion of a sample remedy provision for a service level failure (the provision for a support failure could be similarly drafted):

In the event the software is not Available 99-99 percent of the time, but is Available at least 95 percent of the time, then in addition to any other remedies available under this Agreement or applicable law, Customer shall be entitled to a credit in the amount of $500 each month this service level is not satisfied. In the event the software is not Available at least 95 percent of the time, then in addition to any other remedies available under this Agreement or applicable law, Customer shall be entitled to a credit in the amount of $1,000 each month this service level is not satisfied. Additionally, in the event the software is not Available 99-99 percent for (a) three (3) months consecutively, or (b) any three (3) months during a consecutive six (6) month period, then, in addition to all other remedies available to Customer, Customer shall be entitled to terminate this Agreement upon written notice to Vendor with no further liability, expense, or obligation to Vendor.

< Prev   CONTENTS   Source   Next >