In this article, we will be covering Service-Level Agreement (SLA) credits and the general steps Software-as-a-Service customers must take to recover them. We’ll also go over the typical information required by SaaS vendors, how to collect this information, and how CloudReady synthetics can expedite the SLA credit recovery process.

SLA credits are a type of compensation to customers by service providers when service providers fail to achieve the agreed-upon service levels. These credits are applied to customer accounts as monetary refunds or credits to be used for future services.

The purpose of these credits is to ensure accountability as well as incentivize providers to maintain the highest level of availability and performance possible. When a service provider fails to meet the specific service levels, they return SLA credits as a form of compensation for disruptions and downtime.

How are SLA’s Calculated

Vendor SLAs are typically provided when purchasing or available online, depending on the service. The SLA documentation typically covers the requirements for obtaining credits, providing users with the information required, and the method of recovering said credits. Here are some of the different methods for determining credits owed:

Uptime Percentage: SLAs typically specify a minimum uptime percentage that service providers must maintain. If the uptime falls below the threshold, SLA credits should be dispersed by the provider

Duration of Downtime: SLA usually defines the threshold of the downtime duration for qualifying for credits. As an example, credits may be provided for each hour of downtime after a specific point.

Severity of Impact: Some SLAs differentiate the levels of the service impact. An example of this would be downtime during peak hours affecting services, which can lead to more credits

Calculation Method: The SLA outlines the calculation method for the amount of SLA credits owed to customers. This method utilizes a predetermined formula based on uptime percentage, downtime duration, and monthly service fees.

As part of the calculation method, vendors will typically include the equation users can utilize to determine the credits owed. They are usually formatted along these lines:

SLAs are typically tied to specific products and don’t apply to the platforms unless the entire platform has an outage. For example, Microsoft’s SLA credits are determined by the affected service and time, meaning if an Office 365 customer experienced a SharePoint Online outage, the SLA credits would be approved for SharePoint Online but not all of Office 365.

Example Service Level Agreement:

Required Info

If users believe they are owed SLA credits, the burden is on them to reach out to the vendor to request them. Providing evidence is almost always required; however, global outages documented by the service provider are sometimes enough. Depending on the provider, there may be a cut-off date for requesting SLA credits. Microsoft, for example, allows requests up to two months from the incident.

It is important to collect as much of the required information, usually specified in the SLA, before contacting the vendor. The information and steps required for recovering SLA credits vary from vendor to vendor, but typically consist of the following steps:

1. Review SLA terms
2. Document downtime
3. Calculate credits
4. Contact support
5. Provide documentation of downtime
6. Review and apply credits

The collected documentation should include the customer name, the number of users or locations affected, the length of the downtime, which services were impacted, troubleshooting steps taken, and the ticket numbers when vendor support was involved.

Vendor Outage Notifications

One important thing to note when attempting to recover SLA credits is that vendor outage notifications are in most cases not enough evidence. Even though an outage may have affected users, without additional proof, the vendor can deny the credit request.

When vendors provide outage notifications, they usually express that tenants or customers MIGHT be affected. In certain cases, this may be true where only certain tenants are affected, but without solutions such as Exoprise, providing this proof becomes much more complicated. In certain cases, too much time may pass and the required ‘proof’ may no longer be available.

Collecting Required Evidence Through Exoprise

With Exoprise, tracking and collecting outage information is made effortless. Our CloudReady sensors run continuously, emulating real users. Each time the sensors run, they test the end-to-end performance and availability of SaaS applications. Empowered by crowdsourced analytics, users can quickly identify if a service provider is being impacted.

Typically deployed to offices with user presence, these sensors test the full functionality of a service. The SharePoint Online sensor, as an example, will verify the full login process is successful, uploads and downloads are functioning and collect the SharePoint performance scores, all while collecting the timings for every point of the transaction.

These metrics, once collected, are made visible to users via the sensor or through custom dashboards which can be tailored towards specific applications, teams, or even locations. If any of the timings are too high or any part of the process fails, preconfigured proactive alarms will be triggered to notify the right contacts or even open service tickets via integration or webhook.

CloudReady sensors configured to run on the same networks as users reflect what those users are experiencing. Typically, sensors will identify performance issues and outages before users report them, allowing engineers to get ahead of ticket spikes. By continuously testing and collecting these metrics, identifying and tracking an outage becomes less of a burden, providing visibility into when it occurred and how long the outage lasted.

The information provided by the CloudReady sensors helps narrow down exactly when the outage began impacting users. This data allows Exoprise customers to provide additional proof to the SaaS vendor of locations and users specifically impacted by the outage.

Conclusion

Reclaiming SLA credits is vital to businesses for ensuring they receive the promised value of a purchase, by service providers. By having an understanding of the SLA terms, tracking service performance, and documenting any breaches, reclaiming SLA credits is immensely sped up. In taking these steps, service providers are held accountable, encouraging them to maintain high standards and also fostering a more transparent relationship between them and businesses. By being proactive at recovering SLA credits, businesses interests are safeguarded and ensure service providers always deliver expected performance.