One of the most commonly misused terms in the Information Technology ("IT") industry, even amongst IT professionals and even sometimes lawyers, is that of “SLA” or “Service Level Agreement”. Not all IT contracts are service level agreements even though the term is used loosely and incorrectly to describe almost any type of IT contract.

We differentiate Service Level Agreements from general terms and conditions/contracts/agreements. Both may typically have common elements such as boilerplate clauses, warranties, indemnities, liability provisions, force majeure and the like. However, an agreement which does not contain certain specific elements is not a service level agreement.

It is often said, “what cannot be measured; does not exist” – services are no different. The difference between receiving or providing a good service versus no service is the ability to:

  • quantify the service;
  • measure the service; and
  • address shortcomings in the service.

The difference between an ordinary contract and a true (and arguably effective) Service Level Agreement is the ability to capture the key elements of service delivery. A Service Level Agreement has been described as “An agreement between a service provider or Vendor and the user quantifying the minimum acceptable standard to the user.” [Our emphasis] A well-constructed Service Level Agreement should accordingly have certain key elements:

  • Services Descriptions – this a statement or a series of statements describing exactly (i) what services are expected to be rendered drafted in granular terms; and (ii) how such services will be quantified or measured.
  • Payment clauses linked to service delivery - this may often be determined based on meeting certain specific service levels.
  • Measurement Periods – all services should be measured over a period of time e.g. monthly, quarterly or may even be subject to a specific event such as delivery.
  • Measurement Formulae - this is the actual method of quantifying service delivery e.g. in a cloud computing contract the parties may seek to measure “Uptime” or “Availability” of the cloud service.
  • Performance Level – this will often be expressed as a metric e.g. “99.95% Uptime in the Measurement Period” or “Resolve 100% of all Incidents in time during the Measurement Period.”
  • Exclusions/exceptions to non-performance – common exclusions to service level non-compliance may include things like force majeure, scheduled maintenance, customer default of obligations. These are often negotiated between the parties and service providers may sometimes use this as a mechanism to avoid liability or recourse in the event of non-performance.
  • Critical and Non-Critical Services – this would be a designation of which service levels, if not met, will attract some form of penalty or service credit.
  • Service Credits / Penalties – although not always used as a default, parties often negotiate a penalty for non-performance. In our next article, we will expand on penalties and penalty mechanisms in service level agreements.
  • Reporting obligations – this is a critical and often an overlooked element of Service Level Agreements, it deals with the duty (usually the service provider’s duty) to report on their own performance in each measurement period. A failure to report may often be agreed by the parties to be a failure of all service levels not reported on.

In as much as service levels may be beneficial to the customer, service levels cannot:

  • compensate for poor vendor selection;
  • ensure quality of underlying services or products;
  • measure the value of the services, price efficiency or competitiveness;
  • compensate for a poor commercial deal;
  • address other contractual breaches;
  • overcome poorly negotiated liability provisions and general terms; or
  • result in much or any benefit to the customer if not actively managed through proper governance.