5 Practical tips to set, measure and report SLAs

No matter how much I emphasize the importance of SLA, the love and hate relationship would still be there, especially for IT managers.

This is because setting SLAs is hard, and it’s even harder to measure them.

Here’s an interesting stat related to SLAs:

In a survey from HDI, 66% of their high maturity respondents voted SLAs-met when asked, “Which of These Does Your IT Organization Measure?”

Regardless of the inconvenience, people are measuring how well they are meeting their SLAs because timely delivery of services depends on it.

Another challenge is to configure and change them in today’s service desks.

Before I begin with the tips, I will first cover few basic concepts.

What is an SLA?

An SLA is an agreement in plain language between you, as a service provider, and your customer, which could be internal or external.

Such agreements can be legally binding and can be between organizations or between teams within the same organization.

The premise of such an agreement is to set the service expectations of a customer from a service provider.

Understanding the Difference between SLAs and KPIs

SLA	KPI
It’s an agreement between two or more parties.	It’s a specific metric that measures the performance of an individual, team, department, business unit, project, and company.
SLAs may or may not be aligned to business objectives.	KPIs are aligned to business goals, and they highlight parts of the business moving away from the objective.
Establishes a relationship between the service provider and the consumer.	It’s the way to monitor.
It might have legal implications.	It has no legal implications.

You can also watch this video that beautifully explains the difference between SLAs and KPIs.

First Thing First, Match Requirements and Capabilities of Your Existing SLAs

SLA is an agreement where everything is laid down clearly; related parties know what to expect from each other.

Ideally, there should be no room for mismatch so when creating an SLA keep these things in mind:

• The expectations of your customers.
• Your ability to deliver the service.

You need to have a good understanding of your customers and how they request services.

The same level of understanding has to be there about your own service delivery team. If you already have SLAs set, then do these two things which will help you.

1. Study Your Current SLAs (if any):

If you already have SLAs, get a report on how they are performing. Below is a diagram that highlights the exact steps involved in the exercise.

Having an ITSM tool speeds up the process. With Motadata ITSM, you can create intelligent reports which tells you individual SLA violations grouped by technicians.

Apart from reports, you can have a counter on your main dashboard showing the current number of violations; which will allow you to notice an unusual surge.

2. Create an action plan:

Once you are done with the research, it’s time to conclude and take action.

A formalize action plan is what you must strive for, which might be useful to make your management realize the impact of your work.

In general, your action plan should at least contain the following points in detail.

• A description of the process used to identify SLAs that aren’t performing, which should also talk about the method used to come up with the baseline.
• Findings from interviews and feedbacks taken from customers and technicians affected by the SLAs.
• A conclusion talking about the SLAs that need revision so they can match the expectations of the customers, and the ones that need to be discarded, if it’s necessary.

Consider these two practices to be a periodic review exercise that you should do.

Tip Number 1: Different Services Should Have Different SLA Goals

Not everything coming to the service desk has the same priority; some are more important than others.

For example, failure of a workstation has a different priority as against the failure of a server; one affects an individual another might affect the entire business.

Create a list of categories, that is exhaustive enough to cover all possible incoming tickets; here your experience will come in handy.

The category list will help you in:

• Identifying problematic SLAs if they are created category wise.
• Identifying important categories that require a custom SLA.
• Telling which categories and their SLAs need to be monitored.
• Getting ideas for creating new SLAs.

Now give scores to your categories and rank them, do it both for incident and request. With the ranking done, now you know which categories are important.

Define goals for important categories and set custom SLAs, if required.

The goal-setting process should be backed by data; for example, for deciding on the resolution period you can pull the Average Resolution Time report for that category for a period and make a sound decision.

Motadata ITSM makes adding categories a breeze. Try it for 30 days.

Tip Number 2: Have Default SLAs Based Priority

I have stated earlier that not all tickets are the same; some are more important than others.

Tickets that aren’t covered by a custom SLA has to fall back to something.

Here I would suggest creating a default set of SLAs based on priority (which is present in most of the ITSM tools).

This will hold true for all tickets unless overwritten by a custom SLA.

In Motadata ITSM, priority is a compulsory field which is automatically set for every ticket.

If there’s a default SLA for each priority level then every incoming ticket will have at least one SLA goal to fall to. By the way, Motadata ITSM offers a default set of SLAs based on priority out of the box.

Tip Number 3: Have Escalation Rules Set for Your SLAs

An escalation is what happens when an SLA is violated.

It is important to define escalation rules for every SLA in the system; without them, SLAs are pretty much useless.

Let’s say, your escalation only consists of the assignment function.

Then you can put the entire thing on a spreadsheet before going on to change the SLAs. The spreadsheet might look something like this:

Sr. No.	SLA Name	Response Time	Violation	Resolution	Time	Violation
		Escalation 1		Escalation 1	Escalation 2	Escalation 3
1.	Priority High Tickets	Agent 1		Agent 2	Agent 4	Agent 6
2.	Priority Low Tickets	Agent 3		Agent 5	Agent 1	Agent 2

In Motadata ITSM, you can create advanced escalation rules (both for response and resolution) that will allow you to:

• Modify ticket details like Priority, Technician Group, etc.
• Send an email
• Set a solution
• Change the value of a custom field, and do many more things

Tip Number 4: Set Your Business Hours Properly

The function of an SLA very much depends on time. So, it’s important that you set your business hours properly in your ITSM tool in order to get accurate results.

Ideally, your SLAs should only be active during your business hours.

While setting your business hours keep the following things in mind:

• If you have multiple locations with different business hours then create multiple business hour profiles for each location.
• Make sure to exclude weekends and add an exception for official holidays.

Note: Motadata ITSM also allows you to pause SLAs at certain stages like the approval stage of a ticket. Learn more about our ITSM product.

Tip Number 5: Do Performance Monitoring and Reporting of SLAs

It’s important to monitor your SLAs which will tell you a lot about the health of your service desk.

Monitoring will be of two types: periodic and real-time.

As part of your periodic review, these are some basic information you must have access to from your reporting module:

• Violation count of individual SLA for a particular period.
• Average resolution time of tickets grouped by categories/SLAs for a particular time period. This data point is useful in understanding whether your current SLA resolution time is properly set or not.

Real-time monitoring will allow you to keep your day to day service delivery in check. This will require you to have a dashboard. If you have a dashboard, these are the two widgets you must have:

• A counter showing SLA violation.
• A chart showing the distribution of SLA violations across technicians.