Written contracts covering the provision of software support services often incorporate some kind of service level agreement, or SLA for short. If you have been tasked with preparing or negotiating a software support SLA, and are looking for some guidance, this post should help you.
SLAs may cover more than just software support services. For example, where hosting, hosted services and/or software maintenance are being provided, an SLA may also cover aspects of those services. For the purposes of this post, however, I look only at support services.
What is an SLA?
As with many contractual concepts, naming conventions used in support contracts vary. Whilst the entirety of a software support contract will sometimes be referred to as "an SLA", I think it is useful to maintain the distinction between software support SLAs and software support contracts, with the former forming just one part – albeit an important part – of the latter.
Whether some set of provisions constitute an SLA depends upon their content.
The core provisions of an SLA are: (i) an elaboration of the scope of the support services; (ii) the specification of standards (especially measurable standards) that the services must meet; and/or (iii) the specification of the consequences if the services do not meet those standards. However, an SLA will not always cover all of this ground, and will often deal with supplemental issues.
I return to content issues below.
An SLA will usually appear as a schedule or annex to the main body of an agreement, although it may be a section in the main body.
Because the content of an SLA will be of particular interest to a range of commercial personnel within the service provider and customer organisations – personnel who may have limited interest in the rest of the document – it is usually better if the SLA appears as a distinct schedule or annex. The corollary of this is that formal legal matters (for instance, contract commencement and termination, warranties and indemnities, limitations of liability) should be set out in the main agreement, and should be kept out of the SLA.
Scope of support services
While the scope of support services may be defined in general terms in the main agreement, for instance in the definitions or in the services clauses, a more detailed scope will often be set out in the SLA.
Questions to consider when defining or elaborating the scope of support services include the following.
When third party software is integrated with the supported software or covered by the contract, services relating to that third party software may be subject to special exclusions.
The two core sets of service levels for software support are (typically): (i) response times; and (ii) resolution times.
Consideration should be given to the questions of what constitutes a "response" and what constitutes "resolution". In some cases, there should be express definitions of these terms.
Each set of service levels will usually be organised by reference to the seriousness of the issues giving rise to the request for support services. For instance, an SLA may split issues raised through the support services into "critical", "serious", "moderate" and "minor" categories.
Where this approach is taken, each level of seriousness should be defined. Definitions may be supplemented by specific examples of each level of seriousness. Definitions and examples will vary from context to context, so you should be carefully cutting-and-pasting from SLAs formulated for other circumstances.
Some thought also needs to be given as to the nature of the obligation to meet each service level. For instance, does the service provider have an absolute obligation to respond to requests for support services within the defined time limits, or merely an obligation to use best or reasonable endeavours? This question should be considered in conjunction with the SLA provisions dealing with remedies in the case of a service level breach. Where service credits are to be awarded for a breach, the obligations will usually be absolute.
Service credits and other remedies
In addition to elaborating the scope of the support services, the SLA may also provide for remedies in the event the service provider fails to meet the defined standards of services.
One of the signature features of an SLA is provision for service credits: that is, discounts on charges in the event that the service levels defined in the SLA are not met.
Not all support SLAs contain service credits – they are not as common as they are in availability SLAs – but many do, particularly in the case of high value negotiated contracts covering support for software that is critical or important to the day-to-day business operations of the customer.
However, it should always be remembered that service credits can be a shield as well as a sword. Many provider-drafted SLAs act as limitations of liability, protecting the service provider from breach of contract actions where the services are not up to scratch.
Although provisions covering service scope, service levels, and service level breaches are the core of the SLA, it is not at all unusual to find related matters covered in SLAs. In particular, the following matters may be covered:
Precedents and legal support
The best precedent for an SLA is often one used before by your organisation.
If however you are looking for a template, you should consider SEQ Legal's range of software support agreement templates and software support and maintenance agreement templates, each of which incorporates a template SLA.
Alternatively, if you would like to speak to me about the drafting or negotiation of a software support SLA (or any other software-related legal contract) please do call or email me.
Copyright © 2007-2017 SEQ Legal LLP.