Service delayed is service denied! This is how your end users feel when they don’t get what they want from their IT; in other words, their IT organization is not doing enough.
Now imagine a utopia where people get things, from their IT, when they actually want; now that is something which should put a smile on every IT guy’s face, right?
If you are someone who’s managing your organization’s IT services and want the second outcome, then stick till the end of this article to get 6 insane actionable practices that you can implement today.
In a survey conducted by HDI, 66 % of their high maturity respondents (organizations) measure SLA met for their IT services; this makes SLA important metrics for a lot of organizations.
It’s a challenge for an organization to meet all its SLAs, which doesn’t end by just having an ITSM tool. My six actionable practices will help you to get a hold of your SLAs and prevent the following things from happening:
- Avoiding embarrassing SLA breaches
- Instilling a sense of reliability in the minds of end users
- Aligning SLAs with business priorities
- Making SLA achievements measurable
- Developing reliable escalation rules
The below practices are written based on the assumption that you are already using an ITIL compliant ITSM tool.
An SLA is an agreement between a service provider and its customers. In the context of ITSM, SLA tries to define:
- Response Time
- Resolution Time
An agreement of any sought is useful only when all related parties are on the same page; in other words, there should be no room for over-expectations and under-delivery. So, when you create your SLAs you have to keep in mind two things:
- What are the expectations (requirements) of your customer?
- What your IT services can actually deliver (capabilities)?
Answering the above questions requires you to understand your customers and the situations in which they request services, and your service technicians.
If you are using the Motadata ITSM Tool, then you are in luck. It offers out of the box intelligent reporting that lets you know the violation count of individual SLAs grouped by technicians. Apart from reports, you can create a live counter on its dashboard that will keep a count of ongoing violations.
Your technicians can’t prioritize everything that comes to the helpdesk. A failure of a workstation, affecting an individual, is different from the failure of a server, which might affect the entire business.
Create an exhaustive list of categories that almost maps all possible incoming requests.
Having a proper catalog of categories will help you in the following way:
- It will help you in identifying redundant SLAs. You can create SLAs for important categories. This will also make Practice#1 a lot easier the next time you perform
- Categories will tell which SLAs are important for monitoring
- Mapping services will also give you cues to create new SLAs
After which rank the categories by giving them scores. Now progressively define goals for important categories and accordingly create SLAs. Goals should be created based on statistics. For example, you can pull out a report highlighting the average resolution time of tickets (over a defined time period) from each category, and based on the data spread, you can come up with a resolution period for each category.
Most ITIL compliant ITSM tools support the creation of categories. With Motadata ITSM, in addition to categories, one can create SLAs based on impact; we have three impacts: individual, department, and business. Our tool also allows the creation of separate SLAs for different Service Catalog items.
Not all requests require special attention. For them, you need to create a default set of SLAs. First, you need to identify a field which is mandatory for every request and signifies a sense of priority and has a set of default values.
In our tool, priority is a predefined field, and it is automatically set for every incoming request. Create separate SLAs for each value. This would take care of all other requests that don’t require special attention.
Once you are done with defining categories and goals, it’s time for creating escalation rules.
An escalation is an action or a set of actions that occur when an SLA is violated. For example, you can automatically assign a ticket to a different technician when an SLA escalation happens and for each escalation, you set a different technician, and then you can create an excel for tracking and listing all the SLAs with the names of technicians under each level of violation; something like this:
At a rudimentary level, an SLA is basically a timer. When the timer is up, a violation happens.
In order to make your SLA more meaningful, set your business hours in your ITSM tool and set your SLAs accordingly. Make sure your SLAs don’t run on weekends.
If your organization has a list of holidays, then make sure you add exceptions along with your business hours so that your SLAs don’t run on holidays. Motadata admin setup allows its users to add business hours and a list of holidays.
As an admin, you should know when to keep your SLAs paused. If there are processes, like approval from other departments, where your technicians have no control; there you can keep your SLA paused. This step will ensure your SLA metrics are a true representation of IT services
As a manager, it’s your job to monitor the SLAs actively. You can start by creating mechanisms for periodic monitoring or real-time monitoring.
Periodic monitoring generates SLA reports at pre-configured date and time. Some of the reports that can be created in Motadata are:
- SLA violation count over a defined time period, grouped by category or individual SLA
- Average resolution time over a defined time period grouped by category.
Real-time monitoring will include data visualization that shows data in real-time (as of now). In Motadata, some of the widgets that could be created are:
- A counter showing the number of SLA violation for a particular category
- Graphs showing the distribution of violation across technicians
As you can see managing SLA isn’t easy. Consider the above practices as something to keep you on top of your SLAs.
For those who are still struggling with their SLAs, the practices can be a refreshing guide to get a hold of your SLAs.
Always remember your SLAs are defined by your organizations’ business objectives, and they have to evolve together. So, you have to keep redefining your SLA objectives and monitoring activities. To know more visit