What is a Service Level Agreement (SLA) for SaaS Solutions?
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
Mục lục bài viết
What is a Service Level Agreement For SaaS?
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?
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.
