Breaches in Service Level Agreement (SLA) in SaaS

In this post, we will discuss the basics of SaaS, the service level agreement (SLA), and the breaches in it. We will dive deep and explore the potential types of breaches, their definitions, reactions, and how to avoid them. 

What is SaaS?

Software as a Service (SaaS) is a method of application delivery through the internet instead of downloading and installing that application into your system. It reduces the requirement of navigating through sophisticated software and maintaining it over time. 

SaaS is also known as hosted software or web-based software and these applications run on the SaaS provider’s servers and the provider manages the access, security, performance, and other aspects of it on their end. 

Because of SaaS, you are not required to purchase and maintain hardware that meets the system requirements of the applications you want to use. Instead, you simply need a reliable internet connection with an appropriate speed. As a user of such software, you are also not required to regularly update it as it is done so by the provider.

There are numerous advantages of SaaS including integrated data across your organization, ability to easily customize the application according to user needs, improved access from different devices at any time, and many other benefits. Because there are different types of SaaS solutions and applications, you can easily find one that is appropriate for your business needs, making it a top-notch method of application delivery.

Service Level Agreement (SLA)

Before diving into the specifics of SLA breaches, let’s first understand the basics of Service Level Agreements (SLA). Service Level Agreement (SLA), also known as SaaS agreement, is a legal document i.e., a binding contract that defines and lays out the responsibilities of a SaaS provider and features of their product; essentially, it explains what the customer should expect to receive from the SaaS vendor or provider. It is an incredibly important document in the business SaaS world.

It will generally include information regarding billing, software uptime, quality performance indicators, services and capabilities of the software provided, security, compliance, damages and penalties against the SaaS vendor if agreements or guarantees are not met, and any exclusions for which penalties will not be imposed against the SaaS provider. 

SaaS SLAs primarily include two elements: service agreements and service management.

Service agreements (also called guarantees) include the features, functionalities, and capabilities of the software that is provided to the end-user by the SaaS vendor. 

On the other hand, service management is how the level of service and performance will be measured which ensure that the service agreements are being met. These will include the performance indicators and metrics that will be used to evaluate such performance.

Some examples of such SLA metrics are as follows:

  • Availability
  • Accuracy
  • Functionality
  • Performance
  • User experience

Service Level Agreement (SLA) Breaches

A Service Level Agreement (SLA) are ideal in nature as the provider will do as much as in their control to meet the service agreements outlined in the SLA. However, if any of these guaranteed targets are not met by the provider, thus violating the SLA, we have an SLA breach on our hands.

For instance, a SaaS provider promises 99% software uptime in a month. This means that any downtime more than 7.21 hours is a violation of the agreement and thus an SLA breach as long as such downtime is within the provider’s control and not a force majeure event e.g., natural disasters or third-party actions causing such downtime. 

Determination of an SLA breach

Determining at what point an SLA breach has occurred is important. To do this, there are two things you must consider. 

Firstly, disguised under the fine prints of the contract, some providers will include a clause saying that an SLA breach will only be accepted by the provider if it is reported to them and lodged formally onto their service management platform.

Secondly, the responsibility of producing the proof of an SLA breach is usually on the customer. Therefore, it is imperative that the customers establish their own system of monitoring the metrics to prove to the provider that an SLA breach has in fact occurred. For example, a customer can demonstrate to the provider that the promised uptime was not delivered using their own monitoring system.

Reaction to SLA breaches

If you think an SLA breach has occurred, here are the steps you must take.

The first action, as a customer, is to report and log the issue through the communication channels provided by the SaaS vendor such as email, social media, or a service management system. This may happen as soon as you notice the breach or after a couple of days later depending on the terms of the SLA. 

If the reporting of the issue is immediate, the service provider will have a limited time window within which they are required to respond and address the issue within the set parameters before a breach occurs.

However, if the reporting is later on, the log still stands as a valid proof of such breach as long as this post-even reporting is conducted within the stipulated time duration as highlighted in the SLA.

Therefore, as soon as the SLA breach is communicated to the SaaS provider, it is the responsibility of such provider to open a channel of communication regarding this breach and the potential penalties, as agreed in the SLA, are imposed on the provider.

Stopping the clock

This is a practice on part of the service provider that is shrouded in controversy. When responding to SLA breaches, providers stop the clock. This is essentially suspending the SLA when the metrics being used are based on timeliness. For example, the provider may suspend the SLA when the cause of breach is not within the control of the provider, waiting for the customer’s feedback, or escalating the breach to a third-party. 

This practice may be beneficial for the SaaS provider; however, it is not for the customer as such practice does not reflect the breach in measuring the SLA. This practice has resulted in a “watermelon” effect where the provider reports that all SLAs met (green on the outside), however, the customer faces poor experience (red on the inside).

Credits and Discounts

Many SaaS vendors take into consideration SLA breaches when drafting their SLAs. Many providers turn to service credits and discounts. As the name implies, to cover for a breach, they provide a discount in the next billing cycle. 

This is an easy process; however, it favors the provider as the value of the service lost for the customer is much more than the discount offered. In addition to this, the discount amount is usually capped as a percentage of the total invoice amount. 

Therefore, no customer is satisfied with this way of compensating for SLA breaches as the sales lost due to a downtime on an e-Commerce website would be much more than a discount or service credit offered by a SaaS provider.

SLA breaches processes

SLA breaches require a process to be established and it is not to be left in the hands of an automated platform or a service desk agent. As such, a process needs to be established for SLA breaches and a system of escalating such breaches to the management and concerned personnel for review. 

SaaS providers need to address any consistent breaches formally with a concrete schedule of penalties and consequences. Without an established process of reporting SLA breaches, formal communication cannot be developed between the provider and the customer, and hence, chances of remedy become less as well which will impair customer experience.

Avoiding SLA breaches

Although it is not possible to achieve 0% SLA breaches, it is nevertheless imperative that you, as a customer, take steps in order to avoid and reduce the instances of SLA breaches so that your operations are not disrupted and lead to poor business performance.

Incorporating breaches into the design

Rather than addressing such breaches after the system is live, it is better to factor in the SLA in the design of the service. Do, however, take into notice that you should not try to match a competitor’s SLA because without the given support and resources you might actually be in a worse position as the service was not designed to match your needs.

Problem solving and continuous improvements

Having a framework of problem solving and continuous improvement system is crucial to avoid and reduce the occurrence of SLA breaches. 

By identifying problems, their causes, and the solutions to them and improvements will reduce the chances of SLA breaches significantly. As such, it is important that regular reviews of the SLA and breaches with the provider ensure that it remains updated with the dynamic environment.

Not only should there be a process of identifying and addressing issues but also monitoring and an early warning system should be established that can help reduce the breaches.

Conclusion

Conclusively, SLA breaches cause a lot of losses and need to identified, addressed, and reviewed on a regular basis in order to reduce the chances of occurrence.