SLA Best Practices for ITIL, Help Desk & Service Desk

According to ITIL 4, a service level agreement (SLA) is “a documented agreement between a service provider and a customer that identifies both services required and the expected level of service.” Simply put, an SLA defines what the IT service provider and the customer should expect when contracting for a service.

In the ITIL service lifecycle, SLAs are defined and modified in the Service Design and Continual Service Improvement core areas. This means that SLAs for IT services should be created alongside any specifications for new and updated services. Whenever an IT service is designed or changed, its accompanying SLA should also be reviewed and modified to make sure it is fair, enforceable, and realistic.

Given this, here are six best practices for creating and fulfilling IT service SLAs in an IT service management (ITSM) environment.

1. Create separate SLAs for each IT service you need to measure

SLAs are a collection of promises the service provider makes to the customer. Avoid creating a single SLA for your entire service catalogue. Rather than defining that all IT service requests will be fulfilled in five hours for example, create separate SLAs for each IT service you want to track.

Strive to be specific. Some examples might include:

• A new user will be created within one day of receiving an approved new user request form.
• User terminations will be processed at the end of the user’s last day for friendly departures or immediately for unfriendly departures.
• New phones will be ordered and delivered within one week of request.

Each IT service has its own lead time and approval schedule, which must be completed accordingly.

2. Avoid creating SLAs that cover all your organization’s divisions

If you’re providing support for an organization with many different locations or divisions, be careful creating SLAs that cover multiple locations. Different operating units may have different support requirements, so an umbrella SLA may not adequately support each location.

For example, if you’re providing printer support, the customer may request a response time of four hours between 8 AM to 5 PM weekdays. This may be easy to satisfy in a metropolitan area, where there are a lot of technicians. It may be more difficult to keep that four-hour response in rural areas, where there are fewer technicians living farther apart. This and similar situations may require more detail on services by region or separate SLAs for each region.

3. Align SLAs with the customer’s desired outcome

SLAs should be created for the desired outcomes of the customer. Be aware of the “watermelon effect”, where the service provider is meeting the metrics of the SLA (service uptime, for example), while failing to support your customer’s real goals.

A traditional SLA uses IT operational metrics such as Telecommunication lines must be up 99.1% of the time. These SLAs manage the numbers, but lack context for the customer’s desired outcomes. Instead, use truthful measurements and metrics in your SLAs, reflecting the customer’s actual desired outcomes.

As an example, your SLA may guarantee 99.9% uptime for telecommunication lines. Your testing shows that you’re meeting that metric, but the .1% downtime occurs at the customer’s busiest time, when telecom traffic spikes, like during the NCAA tournament or on Amazon Prime Day. Service drops during those .1% outages and the customer is unhappy. Like a watermelon, the service provider sees a green SLA being met on the outside—99.9% telecom uptime—while the customer sees a red SLA failing on the inside—their users are losing connectivity when the line is swamped.

Whenever possible, discover the customer’s desired outcome for the SLA and write the SLA to that outcome. A replacement outcome-based metric SLA could be Redundant telecommunications services will allow uninterrupted user access between 6:00 AM and Midnight EST. Outcome-based SLAs manage to the customer’s desired outcome rather than managing to a number. Outcome-based SLAs will also affect how you, as an IT service provider, manage the customer’s service.

This important best practice hinges on engaging and listening to your customer while creating and modifying their SLAs. Let them become part of the process so they can understand your service levels and you can write your SLAs to their needs.

4. Make SLAs measurable

Your ITSM service desk must be capable of gathering and presenting the necessary metrics to determine whether an SLA has been accomplished. SLAs must represent SMART goals—specific, measurable, achievable, relevant, and timely.

Each individual SLA must possess the following characteristics:

• Specific. An SLA must be specific and detailed enough to define expectations for service delivery.
• Measurable. There must be a way to track actual performance against the promised SLA. Many service management platforms contain capabilities for comparing SLA promises against the actual time or other service measurement recorded for that item. It’s difficult to accumulate and prove SLA performance if your basic management tools don’t include SLA targets and the measurements used while delivering service catalogue items.
• Achievable. The SLA must be realistic and able to be met. Unrealistic goals can demotivate your service delivery team.
• Relevant. The SLA must be directly related to the IT service being delivered and it must be relevant to evaluating performance against that goal.
• Timely. The SLA must contain a time frame against which the service will be delivered.

An IT service provider must be able to gather data about SLA performance and report on that performance. Make sure your service management software is up to both tasks.

5. Review and adjust SLAs periodically

As part of the ITIL Continual Service Improvement core area, an SLA should be reviewed and updated whenever there are proposed or promised changes for that service. Adjust for any change that affects desired customer objectives such as service hours, availability, uptime, completion, or response time.

Companies who fail to review and adjust their SLAs at times of IT service improvement may no longer meet their service levels targets – and the result could be a customer lost or penalties from SLA non-compliance.

6. Ensure SLAs account for usual and unusual exceptions

It’s just as important to define where an SLA does not apply as where it does apply. Your SLA should define any usual and unusual situations that will hinder or prevent IT service processing.

Some SLA exceptions might include:

• All orders will be released within one hour of receipt, except for Sundays between 1:00 AM and 4:00 AM when system maintenance occurs.
• New computers will be configured and delivered within five business days. Additional days will be needed when a holiday falls within a delivery period.
• New users will be added to the system within one day of receipt of a completed new user form, provided management has approved adding the user. It will not be considered a service level miss if a new user request has been received but management is slow in approving the new user.
• SLA targets will be temporarily waived in the event of a local or regional disaster affecting service, including but not limited to fires, floods, earthquakes, pandemics, extended electrical or network outages, etc.

Additional resources

For more on service level management, browse the BMC Service Management Blog and check out these articles:

• Service Level Agreement (SLA) Examples and Template
• ITIL Service Design Processes
• ITIL Continual Service Improvement

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.