When configuring the Process Block, the following will need to be considered - How must the Requests for services under the SLA be submitted? Email, telephone, customer portal? Who will be able to submit Requests for services under the SLA? Only the Customer's Technical Contacts? What information must be provided when submitting a Request?

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 - _ Support SLA: Available Support Services (for example, assisting users with general non-technical questions) Time timeframes within which these Support Services must be provided The exclusions (i.e. the situations where the Provider will not be required to provide the Support Services - for example, if the user is using the Product in a manner inconsistent with the Product's Documentation). _ Error Correction SLA: Types of Errors (for example, Critical Errors, Urgent Errors and Service Impacting Errors) Timeframes within which a Response must be provided if a Request is submitted to Remedy a specific type of Error Timeframes within which a Remedy must be provided if a Request is submitted to Remedy a specific type of Error The exclusions (i.e. situations where the Provider will not be required to provide the Error Correction Service - for example, if the Product is combined with a Third Party Product that the Provider has not approved) The exclusions (i.e. the situations where the Provider will not be required to provide the Support Services - for example, if the user is using the Product in a manner inconsistent with the Product's Documentation) The Customer obligations (for example, the Customer must provide the Provider with Remote access to the extent required to Remedy the Error.) _ Uptime SLA: The Downtime brackets (for example, bracket 1 - where Downtime is between 95% and 99.99%) The Measuring Period (i.e. over which period will Downtime be measured?) The exclusions (for example, Scheduled Maintenance, Downtime caused by the Customer etc.) _ System Response Time SLA: The System being measured (for example, a third party applications to which API calls are made) How will the process be measured (i.e. the technical description of the process and related metrics) The Target System Response Time The Measuring Period (i.e. over which period the System Responses be measured?)

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: Is there a process that must be followed before Credits are issued? Must Credits be requested within a provided timeframe? How will the Credits be calculated? Will Credits be the sole remedy? Will there be any cap placed on the Credits? Will Credits be forfeited on termination of the Main Agreement? Which exclusions apply to the issuance of Credits? For example, Credits will not be issued if the Service Levels are not complied with in the situation where the service under the SLA was provided as a result of the Customer that was negligent.

Building a Service Level Agreement (SLA)

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.

Most disputed terms WCC ranking:

Most important terms WCC ranking:

Most negotiated terms WCC ranking:

Introduction

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:

While suppliers intend to provide high quality services, SLA Failures can occur over time given the complex nature of technology services. SLA Failures should not be deemed to rise to the level of a breach of contract.
SLAs are intended to underscore supplier’s efforts to maintain the service, proactively identify potential problems, and quickly resolve any SLA Failures.
SLA targets and SLA Credits should be set at levels that drive high performance but do not create financial windfalls for customers or unreasonable financial exposure for suppliers.
SLA performance targets should be measurable and verifiable and should reflect minimum acceptable levels of supplier performance, focusing on critical service elements that are essential to the value of the service being provided.

What is a Support SLA?

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.

What is a Error Correction SLA?

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.

What is an Uptime SLA?

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.

What is System Response SLA?

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.

Building blocks

Process Block

When configuring the Process Block, the following will need to be considered –

How must the Requests for services under the SLA be submitted? Email, telephone, customer portal?
Who will be able to submit Requests for services under the SLA? Only the Customer’s Technical Contacts?
What information must be provided when submitting a Request?

Service Levels Block

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 –

Support SLA:

Available Support Services (for example, assisting users with general non-technical questions)
Time timeframes within which these Support Services must be provided
The exclusions (i.e. the situations where the Provider will not be required to provide the Support Services – for example, if the user is using the Product in a manner inconsistent with the Product’s Documentation).

Error Correction SLA:

Types of Errors (for example, Critical Errors, Urgent Errors and Service Impacting Errors)
Timeframes within which a Response must be provided if a Request is submitted to Remedy a specific type of Error
Timeframes within which a Remedy must be provided if a Request is submitted to Remedy a specific type of Error
The exclusions (i.e. situations where the Provider will not be required to provide the Error Correction Service – for example, if the Product is combined with a Third Party Product that the Provider has not approved)
The exclusions (i.e. the situations where the Provider will not be required to provide the Support Services – for example, if the user is using the Product in a manner inconsistent with the Product’s Documentation)
The Customer obligations (for example, the Customer must provide the Provider with Remote access to the extent required to Remedy the Error.)

Uptime SLA:

The Downtime brackets (for example, bracket 1 – where Downtime is between 95% and 99.99%)
The Measuring Period (i.e. over which period will Downtime be measured?)
The exclusions (for example, Scheduled Maintenance, Downtime caused by the Customer etc.)

System Response Time SLA:

The System being measured (for example, a third party applications to which API calls are made)
How will the process be measured (i.e. the technical description of the process and related metrics)
The Target System Response Time
The Measuring Period (i.e. over which period the System Responses be measured?)

Fees Block

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:

The Fee amount
The frequency of payment of the Fee (for example, monthly or yearly?)
Is the Fee payable in advance or in arrears?
Are there any escalations that will apply to the Fee?
Will any escalation on the Fee be capped if there is a renewal?

Monitoring & Reporting Block

Import aspects that need to be configured as part of the Monitoring Block include:

Who is responsible for monitoring the Service Levels?
How will reporting work?
Within how many days after each Measurement Period must the report be provided?

Credits Block

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:

Is there a process that must be followed before Credits are issued?
Must Credits be requested within a provided timeframe?
How will the Credits be calculated?
Will Credits be the sole remedy?
Will there be any cap placed on the Credits?
Will Credits be forfeited on termination of the Main Agreement?
Which exclusions apply to the issuance of Credits? For example, Credits will not be issued if the Service Levels are not complied with in the situation where the service under the SLA was provided as a result of the Customer that was negligent.

Termination Rights Block

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:

When will the termination right be available? For example, if the SLA is not complied with over 3 consecutive Measurement Periods.

Escalation Block

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.

Out-of-scope Services Block

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:

Which services will be regarded as Out-of-scope Service? Services outside Support Hours?
Will Services provided as the result of a Customer Cause also be regarded as Out-of-scope Service?

FAQs

Is the SLA a stand alone agreement?

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.

Will Software Maintenance Services also be addressed in the SLA?

Software Maintenance aspects related to Updates and New Releases is generally addressed in a separate Agreement.

The Author

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.

Building a Service Level Agreement (SLA)

Table of Contents