Understanding Service Level Agreements for Software as a Service: Key Terms and Best Practices

What is a Service Level Agreement for Software as a Service?

A SaaS service level agreement (SLA) is a document that governs the terms and conditions of services provided by a software as a service provider to a customer. An SLA will typically set forth at a minimum the following: the specific services to be provided, the scope of those services, the duration of the services, payment terms and other general terms ("General Terms") . An SLA will also include terms and conditions relating to service levels (collectively, "Service Levels") and allows the parties to set the standard for performance and the remedies in the event of a failure to meet such general standards. The Service Levels contained in an SLA may vary from agreement to agreement, but typically include the following: uptime availability, problem response and problem resolution, data protection and recovery and other performance and support requirements. Following are some examples of each Service Level:

Important Components of a Software as a Service SLA

There are a number of essential elements that should make up a SaaS Service Level Agreement:
Availability
Service availability is calculated from the point of view of the end-user of the application. The calculation generally includes the times when the service is scheduled to be available to the customers, as well as a provision for lawful downtimes. For the purposes of the SLA, downtime means any period during which the SaaS product is not accessible to the customer. This could be caused by system maintenance, network congestion or other reasons.
Performance
This can be measured either in terms of time taken to complete a specific action- such as the time taken for a payment of an invoice to process, or the time it takes to download an invoice etc.- or it could be a measure of the time taken to access the service by the user. In addition, performance metrics could be shown in terms of CPU usage, memory usage, server resources, etc.
Service Credits
This section of the SLA is a financial one. It provides for service credits to be paid to the subscriber in the event that the service provider does not live up to the terms of the SLA. These are usually in the form of discounts that are applied to the bill of the user. For example, the service provider may agree to grant a 10% discount on subscription fees if the user- an enterprise user whose uptime is critical- experiences an uptime that is lower than 99.5% in a month or an uptime of less than 99% over a three-month period.
Support
The service availability time commitment is different from the help desk hours of the vendor. A vendor may have high standards for service availability, but they may offer help-desk support only 6 hours a day. In such a case, the uptime period may be counted as a success even if there are users who happen to work at odd hours of the day and are unable to get through to the help desk at the time of need. Most support commitments are measured in response time rather than in the hours of the day.

How are SaaS SLAs Different from Other Types of SLAs?

While there are many Service Level Agreements ("SLAs") that exist outside of the SaaS world, the nature of SaaS requires certain distinctions in how they are structured and the services they provide. For example, a traditional SLAs generally measure the quality, availability and maintenance of a company’s on-premise networks, servers and other IT hardware and software. On the other hand, a SaaS SLA is used to measure the availability, latency and performance of the service as experienced by an end user. It is important for companies utilizing or providing SaaS solutions to understand that a well drafted SLA will consider the unique aspects of the technology being delivered, in this case the SaaS delivery model.
The core components of a SaaS SLA include:
• Availability: How is uptime measured: 99%? 99.5%? 99.9%? The calculation of uptime is critical to the success of the SLA. Is the measurement the time that the service is actually available to a user, or is it just the time that the service is accessible over the Internet?
• Support and Response Times: What kind of support can the customer expect? When and how will the issue be addressed? Are these same guarantees made to client’s users? In such a case, who bears the responsibility for such costs?
• Maintenance: What kind of scheduled maintenance is required? Is there maintenance that will be completed without downtime?
• Performance Metrics. In this area, the uptime must be distinguished from the end-user experience. The SLA should set clear expectations regarding response, latency, connectivity and other performance metrics. Who bears the risk if the service is not performing at the levels specified?
• Remedies. What happens if the service level requirements are not met? Does the vendor provide credits to the customer for substandard performance? Does the SLA include service credits offered to users? Are these credits cumulative?
• Termination. The SLA will want to specify how, when and why a customer can terminate the agreement without repayment of any pre-paid fees.
• Transparency. A best practice for SaaS providers is to be transparent with their customers and to proactively report the status of the service. The SLA should specify that reporting and logs will be provided and made available to the customer and its users.

Considerations When Negotiating a Software as a Service SLA

Negotiating a SaaS service level agreement must be done carefully. While you obviously want the lowest possible price to the company you work for, there are dangers in doing so. For example, if a provider’s SLA is too low and the system goes down, a company’s revenues can be significantly impacted. You also don’t want to have to hear from your IT department that they cannot work with the SaaS provider because the provider lacks the capability to run the software that you want them to run.
As with all contracts, the first question to determine when negotiating a SaaS service level is whether the terms are favorable to your company. The first thing you should do is compare and contrast the terms offered by the SaaS vendor with other vendors in the industry. You don’t have to solicit all of the SaaS providers – you can just look at the agreements used by the leaders in the industry (or the providers you like best). In addition, you can look at the terms proposed by a SaaS systems you currently work with as well as new vendors that direct response salespeople have contacted you.
The main provisions to look at include: uptime guarantees, maintenance schedules, acceptable support response times, the amount of refund due to you on an uptime failure, the maximum amount of downtime reimbursement during a year, the amount of monetary damages due to failure to meet the SLA, the exclusions to the other party’s obligations, the thresholds required for the other party to be in breach, the Liquidated Damages clause and the force majeure clause.
Second, a company should determine when the SLA is enforceable. For example, if a company is looking to use a vendor for the first time, it may want to have a guarantee that the SLA is enforceable from day one of the contract period. A company should also determine when claims under the SLA become time barred. A company should also determine whether or not it has a right to obtain credits under the SLA if there is a failure to comply with it. If the SLA includes a refund provision, a company should determine how the refund will be calculated (i.e., a percentage of the license fee or a credit to future purchases). A company should also determine whether or not it has a right to recover other types of damages (such as consequential damages) and attorneys’ fees for breach of the SLA.
A cautionary note here: sometimes the SLA is not a fair "meeting of the minds" at the end of the day. Unfortunately, vendors that offer a very good product at a very attractive price often have SLAs that favor themselves in almost every respect. In this case, all you can do is try to negotiate a couple of provisions so at least you have a fighting chance of collecting some sort of relief in the event your company’s ability to generate revenues is seriously affected by a failure to meet the SLA.
Sometimes a little knowledge is a dangerous thing. Not understanding the terms of the contract that you are signing may have adverse consequences down the road. You should make sure that you understand what your rights will be if the SLA is not met by your SaaS vendor.

Common Areas of Dispute in a Software as a Service SLA

The management of downtimes and service disruptions is one of the core considerations in assessing the efficacy of a SaaS service. Businesses that rely on cloud computing are accustomed to high levels of service and minimal downtimes, and for a good reason; as the use of cloud services has spread, so too have the detrimental effects of service failures. The most high-profile example is the six-day attack that rendered Target’s payment processing system useless for the duration of the cybersecurity breach.
Consider how the Target example would have been different if Target had obtained an SLA from the company providing its payment processing software. The agreement would have outlined precisely what the system was supposed to do, and what the provider’s liability was for a failure. Assuming the agreement was negotiated carefully and in good faith – which is, unfortunately, not always the case – the software provider would have been liable for every dollar lost to the service outage, plus any other damages Target was reasonably able to prove were incurred through no fault of its own.
In contrast, companies that use Google for email and productivity software probably never think about SLAs or uptime statistics – and lucky for them. As mentioned above, those services are largely reliable, and the absence of SLAs helps users avoid liability for losses incurred later. But there is always a risk involved in failing to study – and negotiate – the terms ultimately offered by a provider of SaaS solutions . The terms may be reasonable and largely benevolent, but even SaaS giants such as Microsoft and Google have been known to shut down services and require users to make a mass migration to newer offerings (e.g., Google’s disbandment of Picasa). If each of those companies offered an SLA that said they would continually support each of their services through at least the next five years, would that result be a dramatic change in the way the cloud works? Probably not.
In the world of commercial cloud service providers, however, the vast majority are not giants. A smaller company is less likely to have the resources or bargaining power to support multiple products at once. So while the larger companies are pushing an aggressive move to "the cloud," many smaller SaaS companies are contemplating a more simple business model: Make one good thing and do it well. This is another reason existing SLAs must be considered carefully and negotiated into a more favorable position. Even Google and Microsoft can walk away with little notice, but smaller providers are already at a greater risk of doing so out of necessity.
Additionally, smaller SaaS companies are less likely to have the technical skill and business acumen to develop contracts that are in line with the core value of the services. Unless the SaaS tool can autonomously generate revenue for your company, such as a social networking app, you should be concerned if the SLA offers minimal recourse for system failures (e.g., partial credit on subscription fees), does not cover a significant downtime, or has service times that differ from the three-hour standard that puts pressure on users to identify and address errors.

SaaS Service Level Agreement Best Practices

When drafting a SaaS Service Level Agreement ("SLA"), the parties should ensure that:

• the document expressly identifies each party by their full legal name and as a SaaS Provider and SaaS Customer, respectively, and provides their corresponding addresses;
• a section is included at the start of the document noting the parties’ mutual intentions in creating the document. In particular, it should state that the document is intended to be a legally binding agreement enforceable by them against each other;
• the document contains a section enumerating the points of contact for both parties. In particular, the document should explain that these points of contact shall be the sole point of contact for matters arising under the agreement (unless otherwise stated);
• the document contains a section permitting a party to transfer its rights and obligations to a third party upon notice to the other party;
• the document is signed by each party, with each party retaining an original signed copy. In addition, the document should include a section entitling each party to request a copy of the signed document from the other party;
• the document is written in clear and simple language. The language should not be overly technical and no term should be without definition (i.e. with respect to a defined term that the document spells out);
• the document contains a section sufficiently describing the Customer’s right to review the document and obtain performance data from the other party;
• the document is reasonably formatted, including:

(a) numbering clauses and sub-clauses for ease of navigation;
(b) include a table of contents;
(c) include footnotes and/or endnotes for citations;
(d) breaking up long clauses into sub-clauses and using numbering.

Examples of Software as a Service SLAs

To truly grasp the nuts and bolts of SLAs, case studies and real-world examples can be invaluable resources. We’ll look at some here.
A cloud-based biopharmaceutical software provider was expanding its operations to India and needed an effective way to measure service levels in both the United States and India. "We found that what worked best for us was the creation of a cascading series of SLAs, which we defined as a set of performance measures that focus on the services delivered against agreed service levels," said the company’s director of Service Quality.
The company creates clinical trial applications for the biopharmaceutical industry and had recently moved its applications from hosts to a cloud-based infrastructure. Because the services were now being offered in different locations at different technical environments, it needed an SLA renewal and revision. The new structure consisted of the following parts:
The director of Service Quality said of the structure: "The cascading model is significantly more complex than the former model, but given how each product and region has its unique process requirements, this structure provides the most accurate and transparent way to assess each area’s performance . " Overall, the company said the new structure has created visibility and transparency into service performance results, and has given the company the ability to quickly pinpoint problem areas.
A small software development firm that creates project management software recently adopted a tiered SLA method between itself and its data center support provider. There are 12 tiers ranging from bronze (which is the most basic level of service) to diamond (serving as a pay-for-performance level). Each tier has specific service levels and requirements for response time. Prior to adopting this formal approach, the software firm was getting less than favorable results from its data center provider, despite spending on the average $4,000 a month for the services.
The most obvious benefit the software firm realized was predictability. According to the company’s vice president of Support, "Before implementing the SLAs, our company would have no idea as to whether it was receiving fair value regarding the amount it was paying." Under the revised system, if the vendor does not meet its agreed service levels, it has to offer credits. In this case, the software company was able to negotiate credits totaling $12,000.