Service Level Agreements (SLA’s) are fundamental to effective service provision. They provide the basis for managing the relationship between the service provider and the customer, describing the agreement between the service provider and customer for the service to be delivered, including how the service is to be measured. Basically, SLAs are intended to ensure the provider understands what they are supposed to deliver, the customer knows what to expect, and both can see (empirically) what is actually being delivered.
Regrettably, the ‘agreement’ role of the SLA is lost in many organisations, where SLA’s are used as ‘weapons’ to defend or challenge the provider or customer. The emphasis for SLAs must be on agreement, and the SLA should not be used to hold either side to ransom. A true partnership should be developed between the IT service provider and the customer, enabling a collaborative approach to quality improvement.
Metrics and Key Performance Indicators (KPI) are a core element of an SLA. Ineffective or absent KPI can cause a service to fall into disrepute and a blame culture can develop. KPI for the service must accurately reflect the expectations and perceptions of both the customer and service provider.
To manage service provision, we need:
- Service metrics which reflect the end-to-end quality of service or ‘user experience’
- Process metrics to inform the service provider and customer of the effectiveness (achieving goals) and efficiency (use of resources) of key activities within the service delivery function.
- Technology metrics to inform the IT provider at the component level, enabling the identification of issues and improvement opportunities
The Two SLAs
Customer-based SLA: An agreement signed with an individual customer or a group of customers, specifically designed to cover the services that group uses. You can have one of these, for instance, between a hosting provider and the finance department of a large company to cover things like the finance systems, the payroll systems, the billing systems, the procurement/purchase systems, etc.
Service-based SLA: One of the most used types of SLAs, it implies the same standard agreement for all the customers using the services that are offered by the service provider. Take, for example, an e-mail system for all of the companies. The SLA would cover the whole service provided.
When considering SLA KPI we must recognise that Customer perceptions are influenced by:
- Attributes of service that are indicators of value e.g. relative performance, reliability or security of a remote workspace service
- Present or prior experience of similar attributes
- Relative endowment of competitors and other peers i.e. what they have
- Customers self image or actual position in market (innovator, market leader, risk taker) i.e. do I expect leading edge solutions or accept / expect robust security requirements to access the service
When considering KPI from an IT perspective, we need to recognise that the customer is not excessively concerned with how the provider delivers the service and, as such, is NOT interested in visibility of the majority of KPI which the IT provider uses to manage the service e.g. component performance. On this basis, component and process KPI should not be included in the SLA. They are primarily articulated in Operational Level Agreements and Underpinning Contracts which underpin the SLA. Obviously, certain process KPI will overlap with customer expectations for the service e.g. “95% of incident which impacts more than 50 people in the organisation will be resolved within 4 hours” – customer expectation and Incident Management effectiveness KPI.
We also needs to consider the inclusion of Objective KPI (number of major incidents in a month) and Subjective KPI (Improvements in customer satisfaction).
Finally, we need to consider any scope or constraint measurements that may be required to provide context for current service levels. For example, incident resolution targets or service performance targets may be defined in the context of the number of user of the services (up to 500 concurrent users). In this case, we need to have visibility of the number of concurrent users at any time. It’s a possible discussion for another day but it is imperative that we always consider how we are going to measure each aspect of the service, before including it in the SLA. The mechanism, source and frequency of data collection, processing, analysis and reporting should be mutually agreed between the customer and IT service provider.
So, in summary:
You cannot have an SLA without measurements (KPI)
When selecting KPI, ask, what indicates value to the customer?
- Enhanced performance in the business
- Constraints removed from the business
- Availability & Reliability of the Service
- Performance of the service o Security of the service o Service Continuity (ability to recover from disaster)
Do not include IT ‘management’ KPI i.e. component & process metrics only used by IT.
- Consider “How and how often, can I measure that?”
- Consider Objectives and Subjective metrics
Remember scope measures that may be required for context.
Above all else, do not forget the #1 rule – Nothing should be included in an SLA unless it can be effectively monitored and measured at commonly agreed points.
Source: Bill Heffernan of SureSkills <https://www.gsx.com/blog/bid/43737/the-challenges-of-managing-sla-s-service-level-agreements> Accessed 12th Feb 2019
Note: the article has been edited to meet our requirements.
