When it comes to evaluating the biggest threats to a business’s revenue and reputation, it’s easy to focus on obvious answers such as industry competitors or poor customer service, which costs companies roughly $75 billion every year. 

But one threat that’s constantly overlooked?

Software as a Service (SaaS) downtime.

By the end of 2021, the American workforce will have installed about 380 million SaaS solutions, meaning an overwhelming majority of companies will face serious revenue losses if their business software fails or experiences outages. 

After all, their customers won’t be able to place orders, access the business’s website, connect to customer representatives via phone, or even receive automated advertisements. 

Studies show that small businesses are often disproportionately impacted by SaaS downtime — with over 37% reporting a loss of customers and 26% reporting revenue losses of $10,000-$20,000 of revenue per hour due to system failures. 

To protect businesses and profits from the consequences of downtime, have a Service Level Agreement (SLA) in place between a SaaS provider and the business using the software. 

But what is an SLA, and what should one with a SaaS provider include? 

Read on to find out. 

 

Table of Contents

 

 

 

What is a Service Level Agreement For SaaS? 

 

SLA Development

A sample of an SLA development process. (Image Source)

 

Before we get into any specifics, let’s first answer the basic question, “What is a Service Level Agreement?” 

In the business SaaS world, a Service Level Agreement — often referred to simply as a “SaaS Agreement” — is a legal document and contract that clearly defines both what the SaaS vendor’s product will provide and what the customer expects to receive from the SaaS provider.  

Note that the SLA can either be a standalone document or exist as a part of a larger SaaS vendor contact. 

All different types of SaaS solutions, including CPaaS solutions like business VoIP platforms and web conferencing tools, should offer a Service Level Agreement in order to protect both the customer and the provider. 

We’ll talk later in more detail about what SLA metrics should be included in an agreement, but in general, they’ll include information regarding: 

 

  • The specific services and capabilities which the tool provides
  • Ways in which the quality of those services can be measured 
  • Guaranteed software uptime 
  • Billing
  • Security and Compliance
  • The penalties to be levied against the SaaS provider if guarantees are not met
  • Exclusions for which the provider will not have to pay penalties or be responsible in any way for software maintenance due to user error, etc. 

 

What Should a SaaS SLA Include? 

 

Sample SLA Response Time

A sample of the response time section of an SLA. (Image Source)

 

SaaS SLAs are composed of two main elements: service agreements and service management.

Service agreements (sometimes called warranties) relate to the specific features and functionalities the software provides to the end-user. 

For example, a cloud PBX SLA’s service agreements section would guarantee that the cloud computing platform offers features like unlimited local calling, call recording, conference calling, etc. 

Service management relates to how the service level will be measured to ensure that the service agreements are being met. It will outline metrics to measure the quality of service, dispute resolution and escalation procedures, and reporting processes. 

Below, we’ll take a closer look at the more specific elements of an SLA for SaaS systems. 

 

Guaranteed Uptime 

A SaaS solution’s guaranteed uptime outlines the percentage of time that the software will function correctly, remain online, and successfully adhere to the standards of service clarified in the SLA. 

Though the industry standard is 99.9% guaranteed uptime, (meaning that the software’s downtime is only .1%) most software providers today offer 99.99% uptime. 

This is the most important part of the agreement, as none of the other aspects of the SLA can be met if the tool doesn’t even work properly. 

The agreement also defines how the amount of downtime is measured. 

This online calculator makes it easy to determine the length of allowable downtime under the SLA agreement. For example, a 99.99% uptime means that each year, only 52 minutes and 36 seconds of downtime is acceptable under the SLA. 

The “downtime clock” should begin the moment the software goes offline or stops being able to fulfill the guarantees outlined in the SLA. 

 

Performance Metrics and KPIs 

Once service agreements (uptime, features+functionalities, etc.) are defined, it’s time to determine the metrics and KPIs you’ll use as benchmarks to measure the quality of service. 

Though some may wish to include as many specific data points, minimum requirements, management processes, and features as is possible when drafting the SLA, it’s much more effective to determine which metrics are the best indicators of success. 

Keep expectations high, but also realistic and fair. Companies using the SaaS should focus on the metrics that align with their business goals. 

Remember, the more requirements and higher levels of service which these end-users demand, the more SaaS providers will want to charge for their services.

After all, SLAs have to protect both parties. 

When developing metrics, be as specific as possible. For example, instead of demanding a “high uptime,” phrase it as a “minimum 99.999% uptime.” 

The SLA also covers acceptable error rates (defect rates), a maximum number of monthly security issues, and even specific performance goals like a set number of monthly leads or percentage increase in first call resolution rates.

Finally, consider the methodology used to monitor and assess these KPIs and performance levels. 

The provider will likely want to offer their own performance assessments that customers can view in an online portal. While still valuable, these assessments will undoubtedly favor the provider and look for “loopholes” in the SLA deliverables. 

As a result, customers may want to invest in third-party tools or service standard reviewers to ensure their needs are truly being met. 

 

Response Times and Support Availability Requirements

Response times define the amount of time that the provider/customer has to both respond to a service delivery issue and to resolve it. 

When outlining required response times, clients should prioritize specific support issues and develop the timeframe in which customer service problems should be addressed and fixed. 

“Priority 1” would likely be a complete loss of service, while “Priority 2” could be the loss of one specific feature/function, and so forth. The higher the priority, the shorter the amount of time to respond should be. 

For example, if there’s a complete loss of service performance and the entire system goes offline, the provider should respond within 30 minutes to one hour, with a target resolution time of 8 hours.

In addition to response times, the agreement should also clearly define the customer support requirements the provider must offer — the specific support channels the provider must offer. 

Common support requirements could include: 

 

  • 24/7 helpdesk and service desk access
  • A dedicated customer success manager 
  • Priority phone support
  • Omnichannel support
  • Email support
  • Live chat support

 

Penalties and Exclusions

The penalties and exclusions section outlines what will happen if the customer or provider fails to fulfill the guarantees or meet the performance standards defined by the SLA. 

While customers may think this section generally benefits them, the reality is that it exists just as much to protect the provider. 

Providers usually prefer that penalties exist in the form of service credits, meaning that they will deduct a percentage of the bill or provide free features/services for a set period of time if they fail to meet the SLA guidelines. 

For a detailed example of how service credits are calculated, check out this sample Dynatrace SLA. 

While this is a good solution if the customer is satisfied with the overall quality of the provider, it won’t do much good if it’s clear that the software cannot meet the company’s needs. 

Instead, customers will often demand refunds.

In addition to these penalties, this section will also outline the exclusions — things that the provider is not responsible for providing or paying for when the fault is with the customer. 

For example, if the software went offline because the customer failed to give correct billing information, the provider will not be held responsible. 

This section may also include the indemnification clause, which outlines the liabilities and legal limitations of both parties in the event of a lawsuit. 

 

Privacy and Security 

This section should discuss the security measures put in place as well as data protection and privacy. (Note that in most cases, a longer privacy policy is included in the overall SaaS agreement. 

Make sure there is clear language in place regarding data ownership, as well as the ways in which that data is being both transferred and stored. 

Outline data access restrictions, how long data can be stored, and that both parties understand how the other may be using their data. 

This is also the place to cover data encryption, HIPAA compliance, regulatory requirements, and the response to any sort of data breach or security threat.  

 

Pricing and Billing Structure 

The SLA should also have a section on pricing and billing structures. 

This should define the cost per user, the length of the contract, the frequency of billing (monthly, annually, quarterly, etc.), and the specific cost breakdown of services. 

Ensure that the section differentiates between the cost of monthly/annual services and one-time installation/setup fees.

Ask for a line-by-line breakdown of costs and fees, and ensure that each one can be clearly explained. Vague language like “service fees” should be eliminated or clarified.

This is also where the early termination/cancellation fees should be discussed. 

Define what constitutes an early termination, the exact fee, and outline circumstances in which the termination fee would be waived (for example, customers have the right to terminate if the SaaS tool has consistently failed to provide the services guaranteed in the SLA.) 

Finally, ensure there is room for renegotiation of pricing once the initial contract is up, and avoid an auto-renewal program.  

 

SaaS SLA Best Practices

 

In order to ensure businesses and providers give and receive the highest level of service management possible, follow the below list of best practices. 

 

  • Revise and update an SLA when business needs change, if a current plan is updated, if the company’s workloads have changed, or when industry standards have evolved
  • Ensure SLA KPIs and documentation are developed by both client and provider — not one or the other
  • Create realistic performance targets 
  • Include required document reviews after a set period of time
  • Review examples and templates of SaaS SLA agreements 
  • Ensure the SLA is crafted to fit with any security and industry-specific compliance regulations a business must adhere to
  • Consider offering a 60-120 grace period where penalties will not be applied as a part of a learning curve (this often leads to a more competitive price)

 

The Benefits of an SLA

 

SLAs offer numerous benefits to both provider and client including increased accountability, legal protection, and a higher overall quality of service. 

This means increased service availability, an uninterrupted workflow, and a less-stressed IT service provider. 

Now that you know more about SLAs, it’s time to start exploring SaaS providers. 

Whether your business needs a CRM solution, telecommunication tool, web conferencing platform that’s compatible with your Internet Service Provider, or call center software, our interactive tables of top SaaS providers break down features, pricing and plans, and user experience to help you make the right choice.  

 

Service Level Agreement FAQs

 

Below, we’ve answered some of the top SLA FAQs. 

 

 Though many assume that a licensing agreement and a SaaS agreement (which contains the SLA) are the same things, there are a few key differences between the two. 

A licensing agreement is generally related to on-premises software, where a vendor may deliver and install the related hardware. In most cases, a licensing agreement is renewed on a month-to-month basis. 

The licensing agreement is what gives your business the right to use the software. 

SaaS agreements generally relate to cloud service software, and focuses mostly on the specific services the product provides to the customer.

 SLAs fall into three main categories: customer-based, service-based, and multi-level agreements.

A customer-based SLA is a singular agreement between a company and a provider outlining all services and service levels agreed upon by all parties.

For example, a company providing a virtual phone system may offer bundled services like voice calling, video calling, and SMS messaging. All of these services are defined within a single contract, as opposed to three separate ones.

A service-based SLA is the most straightforward type of agreement, as it states that all customers receive the same quality of service from the provider.

Any end-user who signs a service-based agreement receives the same standard of service, regardless of their role, company, or department. These types of agreements generally give the vendor/provider an advantage.

A multi-level SLA offers the highest possible customization, covering services at the corporate, customer, and service levels. The corporate-level agreement isn’t updated often, as the service standards it outlines generally do not change. The customer-level agreement covers services on a per-customer basis. The service-level section covers all the services a provider gives a company. 

It depends. 

SLA and SaaS Agreement attornies certainly exist to protect both the customer and the provider itself. 

However, SLA lawyers are much more frequently hired by providers than clients, as the providers will want to ensure that they’ll be protected from the financial responsibility of a lawsuit if a customer error results in a security breach, etc. 

Some enterprise-level corporations may also wish to hire an attorney to look over the language of the SLA before they choose to sign it. 

In most cases, however, the company purchasing the SaaS will not hire an attorney.

Yes, negotiation before you sign an SLA with a vendor is not only common, it’s expected. (Often, the negotiation process of an SLA is when customers will sometimes turn to lawyers.)

Common areas of negotiation include: 


  • The pricing model itself (monthly, annually, bi-annually, etc)
  • The length of the contract (often, vendors will offer a lower price in return for a longer contract)
  • Indemnification
  • Out clauses and penalties/fees for early contract termination 

Yes, outsourcing is almost always covered in an SLA. The SLA should include information about the limitations of outsourcing, what the provider is and isn’t responsible for, and any penalties related to outsourcing. 

To protect yourself, try to avoid earn-back clauses, which prevent outsourcing providers from having to provide SLA credits if a higher level of performance is achieved in the future.

If your service provider merges with another company, don’t expect the SLA to stay the same. 

Though some providers will keep the original SLA in place to placate customers, in most cases, the contract will need to be entirely renegotiated and updated.