In this article, we have a look at some of the important aspects that must be kept in mind when drafting a Software / SaaS / API SLA.
Time and time again, WCC data shows Service Levels rank within the top 5 most important and disputed terms.
However, when looking at where Service Levels rank when it comes to Most Negotiated Terms, Service Levels are not even within the top 10 of ranked terms.
The WCC Contracting Principles provide sound guidance when dealing with Service Levels and recommend:
A Support SLA may substantially differ from Provider to Provider and may sometimes even contain aspects that relate to the correction of Errors and general assistance to Customer.
For purposes of this article, Support Service mainly relate to those services a Provider provides to the Customers to help them use the Product.
A Support SLA is therefore a document that details what is required (in terms resources and turnaround times) from the Provider if a user requires assistance with the Product.
When providing Software, SaaS or an API ("Product"), there is always the possibility that there may be a couple of problems ("Errors") that may only come to light once the Customer starts using the Product.
For the above reason, a Provider will provide the Product "as is" with a disclaimer that no warranties are made that the Product is error-free.
From a Customer's perspective, the above may be problematic. What if the Product plays a vital role in the Customer's business? In such a case, the Customer wants to be assured that if they come across any Errors, they will be sorted out (and sorted out quickly if they are severe) so the business can carry on with operations.
A Technical Support SLA is then used to provide certain timeframes within which any reported Errors must be acknowledged and fixed by the Provider.
Uptime SLAs usually relate to SaaS and APIs. If the Provider is required to give an Uptime service level, it means that the Provider must ensure the SaaS / API is working for a certain percentage time over a certain measuring period. For example, if a 99% uptime service level is given for SaaS, the Provider must ensure that the SaaS is working 99% of the time during a measurement period.
These days, businesses are relying heavily on external APIs and Cloud Services. As technology advances and new systems get introduced, the speed which systems need to function becomes vital. These APIs and Cloud Services may be an important cog in their business process, and the optimal functioning thereof is vital.
For the above reasons, businesses generally seek to impose service levels relating to the speed of the APIs and Cloud Services. A System Response SLA is therefore used to provide the service levels at which the API / Cloud Service need to respond once a System Request (for example, an API call) is made.
When configuring the Process Block, the following will need to be considered -
The Service Levels Block is the most important Block forming part of the SLA and contains the quantifiable performance standards.
Important aspects that must be configured as part of the Service Levels Block -
Error Correction SLA:
System Response Time SLA:
There will not necessary be any fees for SLAs.
However, there are situations where a Provider would attach a fee to a "upgraded" SLA especially where there are certain Support Services that take up resources.
In such a case, the Provider may provide a certain number of "free hours". Anything above the provided "free hours", will then be billed at the relevant rates.
Important aspects to be configured as part of the Fees Block include:
Import aspects that need to be configured as part of the Monitoring Block include:
Generally, the go-to remedy if the Service Levels are not complied with are Credits.
Important aspects to configure as part of the Credits Block include:
Hand-in-hand with the Credits Block is the Termination Rights Block.
From a Customer's perspective, if there is constant failure of the service levels, the Customer would want to be able to terminate the Main Agreement without penalty.
Aspects that need to be configured as part of the Terminations Right Block include:
What if the Customer does not get any joy from the support desk? Will there be an escalation procedure where the Customer can escalate the Support Request to a more senior person?
From a Provider's perspective, access to more senior support personnel must only be available in extreme cases and cases where the Customer has opted for a better SLA.
From a Provider's perspective, the scope of the services available under the SLA must be as narrow as possible.
The aspects to be configured as part of the Out-of-scope Service Block include:
SLA's will be generally be incorporated as Schedule to a Main Agreement (for example, a SaaS Agreement) if the document is negotiated.
It is, however, also possible that a SLA takes the form of a policy that is published on the Provider's website. In such a case, the Customer may likely agree to the SLA by way of clickwrap when subscribing to, for example, the SaaS.
Software Maintenance aspects related to Updates and New Releases is generally addressed in a separate Agreement.
Martin Kotze is a commercial lawyer with over 10 years of experience. He specialises in transactional work within the Tech, Financial Services and Property industries.
He is also one of the co-founders at DocNinja and regularly advises companies on how to contract better with their customers and vendors.
This is a free 30min consultation to better understand your business and your needs.