What is a Service Level Agreement?
Service level agreements - SLAs - fix performance standards for specified services in contracts.
So SLAs are categories of contracts which:
- contain a contractually binding legal commitment
- to deliver one or more services
- within stated tolerances.
Service level agreements lock in the performance expectations of the customer, in a legally binding agreement.
So a service level is the measure of the standard of performance by which a business must deliver its services to another contracting party.
If the provider doesn’t deliver within those tolerances, the provider gives credit to the customer for a pre-agreed amount for the failing or shortfall: commonly known as “service credit compensation”.
So many businesses today are reliant on continuity of service and reliability of services. SLAs measure that reliability and provide a pre-agreed legal remedy when it’s not met.
And it’s no surprise when the business’s entire turnover can depend on the reliability IT services.
Here's what we cover:
- "Internal" SLAs: The non-legally binding type
- What SLAs do
- Benefits of SLAs
- SLA Metrics
- Types of SLA Measurements
- Format of SLAs in Binding Contracts
- Types of Service Levels:
- Action SLAs
- Monitoring SLAs
- Defining your SLA
- Priority Levels: Simplifying Service Levels
- Supplier Protections in SLAs
- Collection of Data
- Service Level Compensation: Liquidated Damages
- Benefits for the Service Provider
- Calculating Service Level Compensation
- Change Control
- Scope for Negotiation of SLAs
- SLA FAQs:
- Legal Meaning of an SLA
- 19 Point Best Practices Checklist
- Baseline Metrics
Internal SLAs: The Other Type of SLA
Often “SLAs” is used to refer to levels of service between one different departments or unit within a company.
That’s not what we’re talking about here.
Here, we’re talking about the legally binding type.
Follow what we say here, and you’ll be able spot the differences between one that’s meant to be legally binding, and one that’s not.
And perhaps better define your internal SLAs.
SLAs in Business Contracts
SLAs are a recognition that performance of contracts is not always perfect.
When it isn't within the stated tolerances, the SLA decides what happens.
But SLAs in business contracts can get way complicated. They can cover pages and pages of a contract, with the inclusions, exclusions, priority levels and exceptions.
Without the compensation provisions it is open to argument what the loss suffered by the customer actually is.
So it’s fixed in the contract, and usually named “service level compensation”. In legal terms, they're liquidated damages.
What do SLAs do?
When the defined level in the SLA for service is not met, typically:
- if it’s a minor failure: compensation is credited to the customer in the form of liquidated damages - is payable or credited by the service provider to the customer.
The customer in effect gets the services for a discount, because the services have not been delivered to the defined contractual expectations.
- if it’s a major failure: the customer may have a right to terminate the contract.
When the service level is met, the agreed contract price is paid as usual by the customer to the service provider.
And there’s something else.
A customer is usually entitled to claim liquidated damages when there's a service failing.
Some contracts allow the customer to opt between the pre-agreed liquidated damages or their actual damage suffered by the service failing.
Professional standard SLAs usually include a contractual provision which says that the only compensation recoverable by the customer is that fixed by the service level compensation.
And no more.
That means that the customer is prevented from claiming the potentially much larger sums for their actual damage, rather than the liquidated damages. It depends on the precise wording of the contract that the SLA appears in.
What are the benefits of an SLA?
In a commercial contract, SLAs promote:
- consistency of services: they’re aimed at meeting a known quality of service, by a measurable, quantifiable method
- focus: the parties’ minds are specifically drawn to the standards of performance, and know what the downside will be if the levels aren’t met
- professionalism: the service provider may not be taken as a serious contender for its services without its own service levels
- enforceability: the SLA is the commitment of definable consistency of delivery.
It also narrows the discussion – and disputes – to known, measured quantities.
- customer satisfaction and security: the customer gets the impression – whether do or not is another matter - that they are getting what they are paying for. Less complaints.
- credibility: if a service provider can’t back itself to commit to a fixed standard to deliver, it lacks credibility. Especially when others will commit to an SLA
- negotiations: it creates negotiating points which can be met head on:
- contract control: setting service expectations, what is covered, what is not, and on what terms. They can create contract control mechanisms when the services change or the level of service dramatically increases.
- price point manoeuvring: where higher service levels than those are usually offered by the service provider are requested by the customer.
So how do you obtain the benefit of SLAs?
- empathy, and
They all have one thing in common. They're not quantitatively measurable. These qualities can’t be built into an SLA directly, because they’re qualitative.
They're by-products of a good SLA.
SLAs like these are hard to enforce. They don't have a readily identifiable contractual meaning:
- “Compliance with all legislation, adequate records maintained, zero exposures”: Does zero really mean zero? If so, how can you not be in breach of the service level?
- doing your “absolute best to assist … wherever possible”
- to achieve a “high standard of performance, cleanliness and appearance”: "high standard" - compared to what standard?
- “all waste to be cleared away quickly and efficiently with a minimum of disruption”: how do you measure “a minimum of disruption”?
- “To provide customers with quality food they want to eat”: How do you measure “quality” and “want” in this context?
None of them are easily legally enforceable.
The SLAs should be able to be assessed quantitatively, down to a knife edge.
What puts the Levels into a service level agreement?
Precise, quantitative measurement.
It’s pretty hard to have a credible and reliable service level agreement when the level of service can’t be reliably measured.
Let me explain.
The performance standard – the measurement - should be:
- empirically measurable – ie specific in a measurable sense
- trackable, and
- not subjective or qualitative.
Get this wrong and the SLA won’t work or won’t work as well as you would hope. Then, it might not work at all - if you ever find yourself in a position where you have to rely on it.
That may not matter for an internal SLA.
But it’s a different story when it comes to the legally type.
It’s legally binding because you want to be able to get the intended benefit from the service. And there’s a downside to the supplier if the performance levels aren’t met.
Types of SLA Measurements
The type of measurement varies for different types of services.
You might see them in commercial contracts like this:
SaaS Supplier: A supplier of software as a service, say a SAM system, in the cloud:
- “The Network will be available for 99.XX per cent of the time in any one calendar month.”
- “97% of all electronic mail of less than 1,500 ASCII characters will be dispatched over the Network and received by the intended recipient within 5 minutes of Sending.”
Support Services: for an IT company contracted to handle an inbound IT Help Desk:
- “The Supplier will answer 90% of all Inbound Calls to the Centre within 40 seconds the first ring to the caller.”
- “The Supplier will respond to 95% of all Requests for Support within 4 hours of receipt of the request.”
(Some of the terms above are capitalised. Here’s why)
Business Contracts: Legally Speaking
From a legal perspective, an SLA:
- binds the parties to the expectations fixed by service levels, in the legal sense
- fixes performance requirements with contractual intention
- sets out the downside to the supplier for not meeting the SLA: the incentive to deliver on what it promised
- sets up service level compensation – credits or payments to the customer for failures to meet the performance requirements.
The compensation specifies what the customer will receive as compensation for the shortfall in performance.
- measures performance requirements:
- over a fixed period, and
- by defined event (such as availability of a web service, per delivery, per telephone call).
More on this below.
Turning now to the structure of SLAs: how are they presented in contractual form?
Format of SLAs in Binding Contracts
There’s no reason why the services levels can’t be included in the same contract as the services - or - in a separate, dedicated service levels contract.
It’s more of a commercial question whether they are or not. What suits your business better?
But then customers might have their own model terms for the levels of service that they are after, or their own preconceived ideas about what’s necessary.
Typically SLAs are presented in 3 forms, in either:
- Operative provisions of the contract:
The service levels are embedded into the operative provisions of a larger contract.
Doing so usually makes them harder to change, and more difficult to negotiate.
- Free standing, dedicated contract:
Service levels are presented in completely separate contract to the contract that sets up the services to be delivered.
You end up with two separate contracts:
- the services agreement and
- a separate service level agreement.
The dedicated SLA deals with nothing else other than service levels.
You then have two contracts to negotiate and sign – rather than one.
This might be a better option if:
- SLAs are especially important in your industry,
- it is the standard industry practice, or
- are hotly negotiated.
Having them in a separate contract focuses attention on that document, on it's own merits.
In the end though, it depends what is right for your business.
- Schedule to a contract:
Enabling provisions are inserted into the operative provisions contract, such as:
“The Supplier shall provide the Support Services and comply with the Service Levels in accordance with Schedule [number].”
Then the details of the SLAs are split out into their own separate schedule, with the words,
“The following service levels will apply:”
This isolates the service levels from other unrelated parts of the contract.
This makes them easier to adjust too, because the performance standards are isolated and the enabling provisions. The enabling provisions don’t need to be changed from contract to contract.
You have less contracts to ask a customer to sign, and less explaining to do.
But then some industries have their own well-established standards.
Once you’ve set the structure up, it can be more straightforward.
Types of Service Levels: Action SLAs; Monitoring SLAs
An appropriate SLA depends on:
- the type of service to be supplied, and
- the type of service level which has been agreed.
Roughly speaking, there are 2 basic types of service level:
- a “Monitoring” SLA: For this first type, an SLA applies over a period of time to ensure continuity of a service. The data collected over a period of time reveals whether a service level compensation should be credited - or not, such as:
The service provider will make system available for 99.9% of the time each month.
The provider must to ensure the service continues to function.
It’s an SLA that’s focused on continuity of service.
The SLA doesn’t require the service to respond to event instigated by the customer.
That would be an Action SLA.
- an “Action” SLA: Some positive action is required from the service provider in the near or immediate future in response to a request by the customer. An Action SLA may require the supplier to attend to a hardware fault which stops a single PC from working within a short space of time.
The service provider will replace a Defective Device within 4 hours of Notification of its failure.
The service provider will answer all calls within 45 seconds of the first ring.
So the service provider must take an action - or respond - to an event as part of the services to the customer.
More examples below.
Defining your SLA: What should a legally binding SLA include?
Firstly, define the Service:
- This is the discrete service to be provided by the service provider which is measured by the SLA.
- You need to define the service before you can define a service level for it.
- Each service level sits conceptually “on top” of the service. It's separate to the service itself.
Then, the Customer.
But who is “the customer”?
- The "legal" customer will usually be a company: a separate legal entity.
- You may have different services to be delivered to different groups within the same customer – such as a different departments within the customer, or at different offices of the same customer.
From a legal perspective, you’ve still got one customer.
- But from a service level perspective, when you’re delivering a single service to many service levels, you may have many “customers”.
Such as when you providing services to a different standard to different departments within the same customer.
It’s important to be clear on who the customer is, when each “customer” receives a different service level. That's because
each different “customer” will be a different “customer” for the purposes of the SLA
- For instance: a supplier might provide a 90-minute response time to the Accounts Department, but a 30 minute response time to a Call Centre.
That's two different customers
You should use a different word to refer to the different groups within the (legal) customer to define your SLAs, such as "service receiver". It's draws out the difference between them.
Once you’ve defined what the service is and who it is to be provided to, you’re in a position to define each service level for that service.
Then the Service Level.
There’s no avoiding the detail if you want to get your SLA right.
The structure of (a single) Service Level needs to be defined.
Monitoring SLAs: Service Level Metrics
This is the measure of the level of reliability for supply of the defined service.
The level that must be met by the provider should specify:
- the Qualifying Event:
- in a Monitoring SLA, this will be a metric such as "Availability" or "Uptime"
- the Performance Standard:
- The performance level required over the defined time period of measurement.
- This is the measurable standard by which Qualifying Events are assessed.
- It's usually a percentage of total instances of a qualifying event which must be achieved
- by the service provider.
- Period of Measurement:
- The period of time over which it should be measured
- Commonly over a calendar month, number of weeks or other time period.
Availability of System
System Response to Ping
|[Group of Companies]|
Download Bandwidth of System
> 10 Mbps
10.30am, 1.00pm, 3.00pm Business Days
< 4 seconds
< 2 minutes
The first row above could be translated into a contract to:
The Supplier shall ensure that the Availability of the System shall be 99.9% in each Calendar Month
“Availability” might be defined elsewhere in the contract, to mean:
the Time Available each Month less
- Scheduled Downtime, and
- Emergency Maintenance Time.
"System" would be defined as the service that is supported by the service level.
Each of the capitalised terms is defined in turn in the agreement. That would include the way they are measured, such as response to a ping test from a public facing router.
You’ll know that SLAs can have additional dimensions.
Action SLAs have more dimensions than Monitoring SLAs. They need to be built in to the SLA.
The “Action” in an Action SLA has a performance standard. Then, those actions might be part of an overall performance standard, like so:
Support Request: Email or Portal
80% of Support Requests
Telephone Support Request
90% of Telephone Support Requests
|[Company Name], [Site A]|
Service Request: Defective Device
Resolution (replace device)
75% of Service Requests
|[Company Name], [Site B]|
Service Request: Defective Device
Resolution (replace device)
90% of Service Requests
The second row could be translated into an SLA as follows:
Telephone Support Requests to the Call Centre will be Answered within 60 Seconds. The Supplier will Answer 90% of all Telephone Support Reports within 60 Seconds each Month.
The third and fourth row above:
The Supplier shall Resolve Service Requests:
- from Site A within 4 hours, and
- from Site B within 7 days.
Each Month, the Supplier will Resolve within the Performance Standard:
- 75% of Service Requests initiated by [Site A]; and
- 90% of Service Requests initiated by [Site B].
In this way, you:
- identify the type of SLA you are looking to setup, and then
- adopting the structure the table, and then
- translate it into contractual terms for your SLA.
Priority Levels: Simplifying Service Levels
The more service levels you have the more complicated they become.
When an action is required on a Qualifying Event, different levels of urgency or priority can be included.
The layers of service levels can be compacted and the complexity simplified by introducing a priority level table.
Priority levels allocate different levels of urgency to Action SLAs.
The different performance standards
- apply to the particular service levels in a table
- reflect the seriousness of the failure to the customer’s business, and
- the priority level it should be given.
It’s a priority system to draw out the urgency agreed between the customer and service provider to address the fault.
They’re more easily editable for negotiations.
Priority tables set out different priorities in a grid format. The values from the priority table could be inserted into the Performance Standard column of the table above to maintain the structure of the service levels.
A common model to tie severity to the level of urgency of attention by the service provider is:
They can become multi-dimensional, and more fine-tuned for your requirements.
Metrics for the priority levels might be fixed in a matrix on a granular level, such as this:
The Priority and Business Impact metrics matrix can then be defined, such as:
- The “Business Impact” gradings of “Critical”, “Major” and “Minor” can be defined in the contract. Some (overly) simple definitions might be:
- Critical: “Entire service inoperative”
- Major: “One or more key features unavailable”
- Minor: “Disruption to a feature that does not affect operations”
- Priority levels would be represented as times, such as:
- High: Response Time 1 hour, Resolution Time 4 hours
- Medium: Response Time 5 hours, Resolution Time: 1 day
- Low: Response Time: 12 hours, Resolution Time: 7 days
An Action SLA becomes compressed, like this:
Period of Measurement
Overall Performance Standard
|[Company Name], [Site A]|
Service Request: Defective Device
75% of Service Requests
|[Company Name], [Site B]|
Service Request: Defective Device
90% of Service Requests
Supplier Protections in SLAs
Exceptions and Limitations to SLA Support
No service can be provided without limitations of performance.
If a service level agreement is drafted fairly, it will provide for those limitations.
Service providers will usually (sensibly) insist that they:
- are in control of all facets and components which are involved in delivering the service, and
- can plan for the service levels they are meant to meet;
- limit services levels; and
- avoid liability when they're not within the limits.
Exceptions and limitations are factors taken into account for Qualifying Events.
Different SaaS suppliers will be capable of performing as designed within quantifiable bounds, such as:
- the number of users accessing the system simultaneously
- the limits on disk space available to end users (even OneDrive has a limit of 5 Gb, and Google Drive 15 Gb)
- the number of CPU intensive reports being generated at any one time, which if were run by a small number of users would affect the service performance for the entire user base.
And there will be limitations for all services of any sort. For planning purposes, a support desk can only have a finite number of operatives available to service inbound calls.
There’s always an upper limit to what a SaaS solution can do. Even Azure suffers performance issues.
Exclusionary Terms in SLAs
Exclusions are different in concept to exceptions and limitations.
They’re overarching exclusions that completely void the operation of the SLA.
These conditions disqualify qualifying events – the Qualifying Events are not counted in the service level measurement.
When the events described by an exclusion exist, they’re designed to prevent the SLA applying to the services altogether. Often service providers raise pre-agreed charges in a rate card to rectify faults when an exclusionary events arises, and the service provider is asked to fix it.
- Hardware maintenance SLA:
- damage to equipment caused by the customer
- equipment is moved without the approval of the supplier
- re-configuration of routers
- existence of Shadow IT
- equipment at end of life
- SaaS Software:
- source code used to deliver the services is changed by someone other than the supplier (yes, it happens)
- services are used for a purpose for which they were not designed
- failure by the customer to implement recommendations of the service provider
- The customer doesn’t provide information required by the supplier such as:
- steps to reproduce errors or defects made the subject of support requests when requested
- information required to perform the services.
And others, from a more legal perspective:
- Force majeure events
- The customer is in breach of contract, such as late payments
Mechanics: Collection of Data
For the SLA to work, data needs to be collected.
It is used to measure compliance with the Performance Standard.
Allocation of responsibility for collection usually falls on the supplier. It facilitates the real-world measurement against the performance standard.
It should be automated if there’s room for bias in measurement.
Service Level Compensation: Liquidated Damages
This is the business end of a service level agreement.
SLAs draw a sharp line between acceptable performance and what is not.
Crediting of service level compensation takes place when the SLA is breached. Any failure to perform a contract to the standard set by the SLA is a breach of contract.
What happens if a provider doesn’t meet agreed service levels?
- service level compensation fixes the liquidated damages for the breach – that is, the failure to perform.
Liquidated damages are payable, as set out in the contract would be payable by the provider to the customer.
- In extreme cases, the customer may have the right to terminate the contract altogether.
It becomes a knife-edge situation. Under an SLA you either you meet the contractual standard, or you don’t.
There should be minimal room for argument or discussion.
Performance of Contracts
In one sense, the law doesn’t care to much how the contract will be performed.
When a party agrees to do something under a legally binding contract, the contract must be performed in accordance with its terms.
That’s strict liability for performance.
You could say that the compensation is the incentive for performance of the service provider.
Benefits for the Service Provider
If the performance standard isn’t reached:
- The supplier knows how much it needs to pay. The compensation limits the liability of service provider.
Without fixing the compensation payable, damages are said to be “at large”. It could be any amount.
What's "at large" mean?
The amount will depend on what damage the customer suffered as a result of the service failing. That would be decided in accordance with the law of damages, and all of the complexity and uncertainty that brings
- The scope of the dispute is defined when service shortfalls happen.
SLA compensation levels bring certainty to the contract.
Everyone knows where they stand
Having your own service levels fixes a starting point for negotiations avoids being confronted by the customer's proposed service levels, which might be very different to yours.
Ordinarily, service compensation is claimed by the customer, rather than offered by the service provider.
But the customer needs to be in a position to calculate the compensation, which means having all of the information available to do so.
Calculating Service Level Compensation
A common metric for SaaS providers is Availability.
It’s a Monitoring SLA.
Monitoring SLAs: Compensation
First the calculation for Availability needs to be set out.
Availability = (Total Minutes in Calendar Month - Less Minutes of Downtime) /
(Total Minutes in Calendar Month – Allowed Downtime) x 100
A list of the Service Credit Compensation rates is then applied according to the percentage of availability.
Secondly, the rates applied for the service credit. The formula is applied against that table to arrive at the Service Level Compensation.
In the case of a Monitoring SLA:
|Service Credit Table|
Service Level Compensation Percentage (% of Service
< 100 – 99.95
99.94 - 99.75
99.74 - 99.50
99.49 - 99.00
98.99 - 90.00
Thirdly, make the service level compensation bite:
The Supplier warrants that Availability will not be less than 99.95%.
In the event that Availability falls below 99.95% in any Calendar Month, the Supplier will credit the Service Level Compensation Percentage of the Service Fees nominated in the Service Level Table to the Customer.
In Action SLAs, a similar sliding scale is applied where the performance of provider falls below the minimum accepted level. The essential columns are the service level percentage range and the Service Level Compensation Percentage.
If the services change or the limitations to the services levels change, or the customer wants to change the Performance Standard change, it’s time to revisit and revise the service levels to apply.
Suppose a customer goes through explosive growth and there are no Exceptions and Limitations to the service levels to be met by the provider. More service request and greater loads on support services mean greater expense to the service provider.
Perhaps more than was ever envisaged by the service levels when the service levels where first agreed.
Without Exceptions and Limitations being built into the contract, there’s no incentive for the customer to engage in the process. The clauses need to be built into the contract to invoke the change control process.
Any of the variables associated with the service level may be ripe to be amended - to reflect the reality of the level of service that the customer requires, or the service provider is able to plan for delivery.
Exhaustive monitoring and reviews can get expensive, and be someone's full-time job in a large-scale contract.
Scope for Negotiation of SLAs
The elephant not mentioned above is money.
Change one of the 4 factors above, you'll probably change the price. When the customer wants to receive a higher level of service, it usually costs the supplier more money. The price increases.
Likewise for a lower level: it will cost less to deliver on the SLA.
The norms in the industry play a part in the standard of the SLAs, as well as how critical a business application or cloud service is to the customer.
Large Service Providers
In these days of mass cloud service providers, you’re unlikely to move a giant service provider on terms beyond their standard service offerings unless you yourself are a large consumer of the services. You may end up with better terms from smaller providers.
Due to the principles of freedom of contract, any of these can be modified agreed or omitted.
What’s the difference between an SLA and ...?
- SLA vs Service Guarantees
There's usually no harm in calling it a "guarantee", although it's not. As long as you know the difference.
The legal effect of contracts is decided on the terms of the contract itself, not “labels” used to describe the sort or category of contract it is, or the sort of legal obligation.
One of the rules of contractual interpretation is this.
When the parties – particularly businesses - use technical legal terms in contracts, they are presumed to know what they mean. When technical legal terms are used in a sense that does not match that legal meaning, serious problems with interpretation of the contract come into play.
One of these is the concept of a guarantee. We run through guarantees here.
The tldr is a guarantee is a contractual promise which will be honoured by a third party to the service contract.
So an SLA is not a guarantee of performance.
The difference is that SLAs define the liquidated damages payable or compensation by the service provider when the service level is not met.
If a third party guaranteed performance of the service provider, that would be a guarantee.
- SLA vs KPIs - key performance indicators: KPIs are a flexible concept.
Business process KPIs frequently don’t match and can’t measure what a service provider provides.
The business process for the customer’s own business is ultimately for the customer to decide.
It’s not for the service provider to decide how to deliver the customer’s own services.
For what it’s worth, a service provider should not have much to do with the internal KPIs of the customer business from a legal perspective. Sure, include them in commercial discussions, but keep references to KPIs out of service level agreements.
The customer shouldn’t have too much to do with that, other than designating contacts within their organisation.
If KPIs are to be agreed, it’s probably a good idea to keep them separate to service levels. You avoid confusion in the SLA contract about legally binding commitments.
You can see what happens when KPIs are put into contracts in Sutton Housing Partnership Ltd v Rydon Maintenance Ltd  EWCA Civ 359.
It becomes well-complicated and confusing.
As they’re so unclear from a legal perspective, judges will make up their own minds about what the KPIs and the contract actually mean based on the evidence.
- SLA vs MSAs - Master service agreements: Master service agreements set up the services to be performed by the service provider. It may – or may not - include specific service levels.
When they do, they are often in a separate schedule to keep the them all in one place.
- SLA vs OLAs - Operating level agreements: Loosely speaking, OLAs define how services will be delivered by the service provider.
They’re documents made to organise services, for organisational purposes.
These shouldn’t set out SLAs – ie the performance standards that needs to be met by the service provider.
SLAs “don’t care” how the services are delivered.
They just care about how they are measured and the compensation payable by the service provider when they aren’t met.
- SLA vs Outcome-based pricing models: These are models which tie payment of the service provider to a commercial business result.
They’re like SLAs in reverse.
- With a service level agreement, the service provider gets paid an agreed amount for the services. Then sums are subtracted from that if the service levels aren’t met.
- With outcome-based pricing, the service provider gets paid a baseline amount, and then topped up if the service level is achieved.
They’re opposite sides of the same coin.
The same fundamental principles apply to both.
- SLA vs Charter
A charter is similar to a mission statement – desired outcomes.
They operate as:
- statements of policy – which aren’t specific enough to be legally binding at all, or in any predictable way
- overall goals and objectives of an organisation, such as “to consider and respect your privacy, dignity and cultural beliefs”
- statements of reassurance for users of an the organisations services
They’re also statements that lack legal meaning and aren’t legally binding in any meaningful sense. In the same way as Internal SLAs.
What’s the difference between:
- Customer-based SLA:
- One customer, one service, one set of service levels
- Service-based SLA:
- One customer, one service, multiple set of service levels
- There’s one service for all customers. Different service levels commitments apply to different groups within the (the same) customer.
- For instance, members of the board may have a higher response and resolution time to employees in the warehouse
- How do you handle these in a contract? Define different sub-customers.
- You don’t need a different legally binding contract with each subgroup within the organisation
- Multi-level or Hierarchical SLAs:
- Many customers, one service, many set of service levels
A service (supported by an SLA) could be provided to:
- Many customers, one service, many set of service levels
- an entire company
- a group of related companies
- separate departments within a company, or
- some other subset of a company or group of companies.
It’s a matter of knowing who the customer is.
You might have one customer, but provide one service with different service levels within the organisation(s).
But it really depends what the contract says.
Is Service Level Compensation a penalty and not enforceable?
True contractual penalties are not enforceable at law.
The reason they’re not enforceable is that the measure of compensation vastly exceeds the greatest amount a customer could receive by way of contractual damages.
That’s not to say that references to “penalties” in service level agreements are unenforceable.
Courts look to the substance of the compensation payable in the circumstances of the contract and the case at hand to decide whether the credit or sum to be paid by the service provider is genuine compensation or an (unenforceable) penalty.
Even if the compensation which would be payable is properly considered a penalty (and unenforceable), the customer is entitled recover the sum of their actual loss in damages – rather than it being a liquidated sum.
What is Benchmarking?
Benchmarking an SLA is discovering:
- the metrics and
- their levels which will need to be reached for a minimum viable service.
There will be a difference whether it’s a Monitoring SLA and Action SLA.
Can we create SLAs for shadow IT?
Shadow IT can interfere with the services, place unexpected loads on IT services and cause corruptions to configurations which keep computer systems and network in a stable operating condition.
If something’s out of your control like shadow IT, you’d need to think twice before you’d commit to a service level for it.
A service provider might think about:
- providing for Shadow IT as an exclusion to service level commitments, not and not to apply where a user has sought to fix it themselves.
- the unpredictability of Shadow IT and provide service levels based on a rate card.
Is an SLA transferable?
An SLA which forms part of an existing legally binding contract will be transferable by novating the contract to another service provider.
Novation is where the existing supplier and customer agree that the existing supplier will be replaced by a new incoming supplier, and the incoming supplier agrees to accept contractual responsibility for the services and the service levels.
What is an indemnification clause?
Or put another way, is an SLA an indemnity?
An indemnity is something very, very different to an SLA.
Indemnities contradict the purpose of known or calculated value of service level compensation.
An indemnity for a service level breach would allow the customer to recover all losses caused by a failure to meet a service level, rather than the predefined limit.
An uncapped indemnity would place the service level compensation at large (ie unquantified) and not fix it to a known value in the contract.
Where an indemnity changes the entire scope of risk in signing up to an SLA (dramatically, upwards).
What are Earn backs?
Suppose a service provider fails to meet the required levels in a given month.
Earn backs are a mechanism to make good on previous service failings by over-performing in later months.
There’s no reason why a bonus can’t be agreed to be paid for exceeding the objective standard by defined criteria.
Are there limitations on SLA claims?
Watch out for time limitations on claims.
These prevent claiming service level compensation a fixed period of time after the relevant failure took place.
Limitations can also take form in limitations of liability clauses.
You need to read the entire contract – carefully – to find them.
Although you and I may talk about these terms, it is how they are defined in the contract that counts.
Not what you and I might understand them to mean in discussions.
We have it from the Supreme Court, in Wood v Capita Insurance Services Limited  UKSC 24 per Lord Hodge at paragraphs 10 to 13.
The court's task is to ascertain the objective meaning of the language which the parties have chosen to express their agreement.
Contractual meaning is to be assessed in the light of the natural and ordinary meaning of the provision in question, any other relevant provisions, the overall purpose of the provision, the factual matrix and commercial common sense but disregarding subjective evidence of any party's intentions.
Interpretation is a unitary exercise, involving an iterative process by which each suggested interpretation is checked against the provisions of the contract and its commercial consequences are investigated.
What this adds up to is this: If your contract is not clear in its terms, it becomes a complicated process to work out the legal effect of the contract. This includes SLAs.
Trust is important in any relationship.
But then that trust wont help you when a catastrophic failure takes place that cant be fixed on a commercially realistic timetable.
Test your SLAs with scenarios. Dream up variations, and don’t forget the extremes.
You could get someone else to do it, because you’re probably too close the action and can't see the detail with clarity anymore. This tests your metrics independently for a health check.
If you can't calculate them with the data you have, you have you may need to drop your proposed metric and come up with another one that you can support easily.
Service levels affect price. Service level could be impossible, unrealistic or even unnecessary.
Importance to service delivery needs to be weighted.
If the services change, the SLA should change.
Service Level Agreement Best Practices Checklist: Tips
Setting Up your SLAs
- Structure: SLA should be entirely self-contained in one place in the contract, whether in a standalone contract or a schedule, unless you've got good reason not to
- Separate Service from Service Level: Distinguish between the service itself and the service levels to perform it
- Classify your SLAs into Monitoring SLAs or Action SLAs to set up the structure of your SLAs, so you can deal with them separately
- Be specific. This one of the main ways to tell a good SLA from a weak one.
It shouldn’t read like an ISO standard, a policy document, wishful thinking or a statement of intentions.
- Avoid agreements to agree service levels. They’re not legally binding, other than very rare circumstances. Assume they won't apply to you.
- Avoid Self-Defeating SLAs
It’s self-defeating to both parties to agree:
- factors which aren’t within the direct control of the service provider
- to service levels which can’t be delivered.
Metrics should relate to performance level of the supplier.
Avoid vanity metrics.
- Response Times and Resolution times:
- Response times and resolution times usually allow for business operating hours. Or should they run continuously 24/7? Make it clear what's intended
- Automated responses are not ideal from a customer's perspective, but are from the supplier's perspective
- Ensure resolution times are realistic
- Urgency/Severity/Priority Levels:
- Deciding the priority levels: Allow the supplier to select the appropriate priority level first.
- If that selection is unreasonable, the customer should be able to reallocate it
- The definition of qualifying factors for priority are important to get right
- Service Level Exceptions and Limitations:
- Define the limitations of the service levels
- Define the events which prevent the service provider from delivering to the service levels
- Change Control:
- Protect the service provider from dramatic increases in service requirements
- If the services change or a limitation is exceeded, it should prompt a review meeting and forcible changes to the SLA. Quickly.
- Define the events which disqualify performance to the service levels
- Define rate card rates for services provided which fall into an exclusion
- Collection of Data:
- Collection of data should be automated to avoid bias, and distributed to both parties automatically
- Service Level Compensation:
- The aim of service level compensation should be to compensate, not punish. it's not conducive to a good working relationship
- Is service level compensation the sole remedy, and all other remedies excluded (such as termination)?
- Are time limitations on claims a under the SLA appropriate?
- Decide with the supplier offers compensation where a shortfall, or whether the customer must request
- Option to Terminate: There is failing to meet a service level.
And then there is seriously blowing it.
There should be a threshold to permit the customer to terminate the contract if there is a serious and unforgivable shortfall on one or more service levels.
What kind of metrics should be monitored?
Here’s a baseline of different types of core metrics that can be covered in an IT Service Level Agreement:
- SaaS and Cloud-based Service Contracts:
- System response times
- Bandwidth / Throughput
- Response times
- Resolution times
- Online Backup services:
- Bandwidth throughput
- Recovery time
- Defect rates
- Hardware Maintenance Agreements:
- Response times
- Resolution times
The real interplay here is with the type of devices which are covered by SLA - the covered maintenance tasks. If say, it's a disk drive that fails. If replacements aren't on hand, a 4 hour resolution time is unrealistic, even if support is suspended out of business hours.