What is a Service Level Agreement?
A service level agreement (“SLA”) is an agreement between a service provider and its client, the user of its services. The service provider can be internal (such as the legal department or IT Helpdesk) or external (such as a hosting provider, a SaaS supplier or a backup service provider). The SLA’s primary purpose is to define the level of service the user will receive, not the specific mechanics of service delivery. SLAs can be provided for any industry and the categories of services and the levels of the service will vary with the industry.
Typically, as a Software-as-a-Service (“SaaS”) supplier, you provide a software application service through a hosted environment that is accessible to end users through the internet. Your SaaS SLA will likely service levels around support and hosting. While SLAs may be stand-alone agreements, they are usually included as part of the master SaaS contract in line with the main body or as a schedule to the agreement.
As a SaaS supplier, your support service levels will typically address what kind of support you will provide the user (error fixes, regular updates etc.), hours of support, how quickly you will respond to an issue, and how frequently updates are made to the system. Hosting service levels relate to hosting aspects of your SaaS – how long the system will remain available during a given period, frequency of backups, levels of data security that may be implemented.
You may provide additional service levels related to the specific functionality of your SaaS. For example, a SaaS product that deals with providing reports may have SLAs around frequency of reporting and the accuracy of the reports.
Expected Performance Level of the Service
The SLA will define what level of performance the customer can expect. Specifically, the SLA will describe when the service is available and how reliable the service is.
For example:
Support: “Telephone support is available between 9:00 am and 5:00 pm on weekdays, except statutory holidays.”
Hosting: “The service will be available 99.5% of the time in any given calendar month.”
When setting out the performance level of the service, consider any dependencies it may have. For example, if the hosting piece of the service is provided by a third party, such as Amazon Web Services. When setting your availability service level you should factor in the availability guarantee your hosting provider has with you. Additionally, you will likely not have control over the client side of the communication or the performance of the network (usually the internet). These constraints should be considered when describing the performance service level.
A typical SLA for availability would exclude from its calculation any downtime beyond your control such as due to general network slow-down or client server problems and would typically be no better than the service level provided by the third-party hosting provider.
Response Time and Resolution Time for Support
The response time is the time it takes your support team to respond to your customer’s problem report and to start investigating the issue. Response times may vary depending on the severity of the issue. Issues dealing with partial to complete outages will typically have very short response times, while support personnel may take a few hours to respond to less urgent requests such as minor functionality not working. Response times are typically provided in the form of a matrix. For example:
| Severity of issue | Response Time |
| Severity 1 (high) | Within one hour of receiving the report |
| Severity 2 (medium) | Within four hours of receiving the report |
| Severity 3 (low) | Within one business day of receiving the report. |
Sometimes the customer may require the SLA to specify “resolution times”’ in addition to response times. Resolution time is the time it will take you to resolve the issue and restore the service back to normal. Since a SaaS product has many dependencies, debugging an issue may be tricky, and it can be hard to predict how long it will take to resolve. Therefore, avoid providing resolution times or provide them only for the most predictable issues.
Since response times are based on the severity of the issue, ideally you should have sole discretion in categorizing the severity level of the issue. However, customers may not like this. An alternate and more acceptable approach is to have objective definitions for the severity categories – for example: severity 1 could be defined as a complete outage of the system, while a severity 3 could be emails not being sent out through the system. Of course, the severity definitions would be dependent on the type and criticality of the SaaS product, but should be consistent across the whole customer base.
Remedies for Missed Service Levels
Your customers may require that you compensate them for missed service levels. The customer may also want the right to terminate the master contract if you are not meeting your service commitments. These consequences can have a significant financial impact if not set out carefully.
Compensation for SLA violations is often a fixed amount or calculated as a percentage of the monthly fee for the service. In order to ensure positive cash flow for the contract, the sum of the credits for the fee period should not exceed the total fees payable by the customer for that period – i.e., you should not be in a situation where you owe the customer for the use of the SaaS service for that period.
Compensation for a missed service level should be provided as a credit to the customer against future fees for the SaaS product. As far as possible, avoid cash reimbursements for missed service levels – these unplanned disbursements could turn out to be cumbersome especially if the violated service level affects a large portion of you customer base (for example if there is a server outage, this could cause all your clients housed on that server to lose service for an extended period of time, triggering the service level remedy for each of them).
Your SLA should specify a time limit before which your customer can report a breach of service level. This will prevent them from claiming service credits months after the fact when you are not expecting, affecting future cash-flow in unintended ways.
Customer’s termination rights for missed service levels should be considered only for egregious violations of the SLA – for example, when there are repeated violations in a short period of time or if the violation could have disastrous consequences for the customer. For example, the customer may be allowed to terminate the agreement if the customer misses the availability SLA for 3 months in a row.
Service Level Monitoring and Reporting
The SLA sets out how service levels are monitored and reported. This would include who monitors outages and compliance and the process for reporting missed service levels. An SLA could also describe any statistics to be reported by the vendor on a regular basis, such as number of missed SLAs, average response times and total downtime for hosting.
Customers may expect you to be pro-active in monitoring service levels and reporting any violations to the service level along with providing associated credits. Such an approach should be avoided as it can be quite cumbersome to prepare reports for each customer and issue individual credits. Alternately, the SaaS vendor could provide the customer with access to available service level reports (for example, through a portal) and a mechanism to request service credits.
Setting your SaaS SLAs
In order for your SaaS to be scalable and consistent, you as a SaaS supplier should ideally provide the same levels of service to all customers. You can also have different tier levels of service at different price-points as long as all customers in the same tier level receive the same level of service. For example, you may provide 24/7 support for a gold-tier customer. For your other customers, you may provide support only between 9:00 am and 5:00 pm on weekdays.
Look to historical patterns when setting your service levels to minimize the likelihood of them being violated during the normal course of operation. Missed service levels may lead to financial impact such as service credits owed to customers and cancelled contracts.
Managing your SaaS SLAs
Once set, continuously monitor your service levels to ensure that you are meeting them. You may find that are missing service levels on a regular basis. If so, you may want to consider re-evaluating and renegotiate the service levels with your customers so that you are able to meet them consistently. Alternatively, you may want to adapt the SaaS service through additional resources, reconfiguration or other means so that you are able to better meet the already negotiated service levels.
Regular monitoring may also highlight that you are able to provide a higher service level which could be a competitive advantage in attracting and retaining customers.
Summary
Summarizing, keep the following in mind when setting and negotiating SLAs.
- Consider third parties and external factors that could influence the services when setting service levels
- Avoid agreeing to resolution times. Consider response times that are appropriate for the severity of the reported issue.
- Avoid taking on the responsibility of providing customized service level reports to the customer. If available, the customer may be given access to certain non-confidential reports that could assist the customer in monitoring performance against the service levels
- Avoid issuing cash reimbursements for missed service levels. Cap total service credits to be issued for any reporting period and allow termination only for egregious violations of the service levels.
- As far as possible, keep service levels consistent across the customer base to allow for scalability. If necessary, different bands of service levels can be considered, but avoid customizing service levels to each customer.
- Consider modifying and renegotiating service levels with customers or adapting the SaaS product if service levels are consistently being missed.
A good SLA should be consistent across all customers and minimize administrative overhead and financial impact while allowing you to remain competitive in the market place. While negotiating an SLA, when in doubt, get input from the technical, financial and legal teams to ensure that these objectives are being met.
3 Responses
Thank you for an informative article.
Question: When compiling an SLA, and the associated DPA etc., is it worthwhile using an online service such as approovd.com to build the contract before passing to a Lawyers for checking? Or does this create additional cost/work for them – and myself as the customer? I am focused on the German/Swiss market.