We all seek to provide better service, faster, more effective and more efficient service, surpassing the standards in our respective markets. As a service provider, the ever-growing expectations of our customers are a priority. The IT department is no exception and should ideally involve the management in establishing KPI practices from the conception of its services.
What is an SLA?
ITIL defines a service-level agreement as an agreement between two parties, where one is the customer and the other are service provider. An SLA is most effective when the IT service provider and the business customer collaborate on what should be included. Any SLA needs to be agreed upon by both parties. This becomes a guideline for managing the relationship between the customer and the IT Service Provider.
All metrics included in an SLA should be measurable. These measures should be taken and recorded regularly. Generally, these metrics will cover the hours of service and service availability.
The Role and Benefits of Defining Service-Level Agreements
The purpose of this Service Level Agreement (SLA) is to identify the basic services, and any agreed upon optional services to be provided by the provider regarding the system for the client. It clarifies the responsibilities between the IT service provider and the customer and provides both parties a framework and a common understanding. Finally, it established specific objectives to reach and the measurements, follow up and reporting needed.
In terms of benefits, we note that SLA helps :
- Identify the service provider's weakness to place improvement actions.
- Identify client and user actions that draw incidents to improve those situations.
- To gradually improve service quality.
Best Practices
#1: Because an IT SLA can be used to describe various IT services, the particular elements included in an SLA will depend on the circumstances. A good SLA addresses:
- What service(s) are being made available to what customers?
- What level of service or quality of service should the customer expect?
- What are the costs of providing this level of service?
- How will the service be delivered?
- How will the service provider monitor or track and report on performance?
- When will the SLA be reviewed?
#2: An SLA is not a technical document and should be written in business terms. Everyone needs to be able to understand it.
- Use clear and concise wording and avoid ambiguity.
- Avoid legal and technical jargon.
- Avoid unnecessary technical terminology.
- Provide a glossary of terms if necessary.
- Have someone independent from the process review the SLA.
#3 : A good SLA must describe the service the provider promises the customer.
- What systems are supported?
- What services are included? What services are NOT included?
- How will service be delivered?
- What are the hours of operation (regular business hours and after-hours support)?
- When will regularly scheduled maintenance be performed?
#4: The metric is the center of an SLA, they must be determined in the contract and constantly measured. Choose metrics that are easily collected. Balance the importance of a desired metric against its ease of collection. Avoid including excessive metrics in the SLA that can’t be analyzed on time.
Metrics Examples
Metrics being at the center of the service level agreement, assessing their relevance and identifying good indicators is crucial. Here are some :
- Response Time: This metric defines the maximum system response time. For example, 95% of users will experience a response time of two seconds or less during regular working hours of 7:30 to 5:00.
- Throughput: This metric defines the data delivery rate to the customer. For example, a file transfer/download of at least x mb (file size) will be transferred in x minutes.
- Utilization: This metric defines the maximum usage during which the system will perform within guaranteed response times and throughput. For example, this metric could specify the maximum number of simultaneous users.
- Customer Support: This metric includes the typical help desk problem reporting and problem resolution guarantees based on severity level. Severity level, response, and resolution times are assigned according to their impact on customers. The IT Service Provider and the Customer negotiate the acceptable response time and resolution time.
- Availability: This metric includes system availability guarantees over a period of time. For example, the application will be available 98% of the time, 7 days a week, 19 hours per day.
It is also possible to build arrays of priorities based on criticality and response/resolution times.
SLA Examples
To clarify you your service level agreements with your customers, here are some concrete examples of SLA :
Continual Improvement
Although the performance indicators listed above represent elements of continuous improvement (CSI), you can audit these measures to optimize the current evaluation program. For example, you can measure the number of service/process assessments, the number of weaknesses identified and the number of completed or started initiatives. This retroactive effort enhances your continuous improvement program and improves customer satisfaction. This exercise loop can also be deployed horizontally across the organization and serve as a measuring tool for different departments or teams.
- Number of services covered by SLAs
- Number of services evaluated by SLAs, where weaknesses and corrections measures are reported
- Number of services by SLAs that are regularly reviewed
- Number of services by SLAs where agreed service levels are met
- Number of issues in the provision of the services which are identified and addressed in an improvement plan
To conclude, the introduction of SLA allows you to better manage your customers’ expectations, perform metrics monitoring and thus constantly improve service. To do this, however, it is essential to define the roles and responsibilities of each clearly. ITSM will also allow you to regularly check your delay and more easily calculate metrics.
