If you are heading IT Operations or Support Desk or IT in general, then you know that end user behavior has changed significantly and continues to change. This means, the Helpdesk implementer has to either implement effective and optimal solutions or get out of the way.
For non-ITSM readers, let me define what is an SLA
SLA stands for Service Level Agreement. At a high level, it is an agreement / understanding between service provider and customer by when the issue/service needs to be responded and resolved.
If the agent or technician or support desk personnel of service provider does not respond or resolve the issue/request on time, it should be escalated to the second level. The process may continue further, if it needs to be escalated to the third level if it is not responded or resolved by second level either.
This helps in tracking the services and performance of service provider as against agreed agreement. This also helps in measuring customer satisfaction pragmatically and in a transparent way, rather than using vague parameters. For instance, CSAT (Customer Satisfaction score) may be defined as meeting 99% of response SLAs and 97% of resolution SLAs.
Now that you’ve background on it, let’s get down to discussing on where most of the implementations may go incorrect if SLAs are not understood correctly.
Common criteria of defining SLA
Interestingly, most of the customers presume that they are ready to define Service Level Agreement, only to realize that they are not, after they listen to our questions carefully. The business requirements for defining SLA may vary as you can note from below options –
- The most common approach used by most of the customers is to define SLA based on priority. Some would further expect priority to be computed based on impact and urgency.
- Few customers define SLA based on category and sub-category.
- Few customers define SLA based on priority, category and sub-category.
- Few would need it to be defined depending on time zones of the agents/technicians.
- Some of the businesses expect it to be depending on time zones of the end users/end customers.
- There are instances, where the SLA was really expected to be defined based on locations!
- A few would define it based on contract type – Platinum, Gold, and Silver etc.
Ask questions, ask the same questions to different stakeholders and ensure that you have understood the requirements. Also, validate that your customers have understood what SLA would be implemented, by offering some POC (proof of concept) or by explaining it with examples.
Conclusion
Typically, SLA would’ve to be defined based on one of the above explained scenarios. Do not be taken aback to know that many of the customers wouldn’t have even thought through the process. They end up just stating SLA needs to be implemented, without defining criteria towards it. You may have to explain the importance of defining SLA correctly. Why? Think of it, the average cost of resolution per ticket for North America varies between USD 22 to USD 471 (refer The Paradox for more details)
Defining SLA correctly is the most critical part of any Helpdesk or ITSM solution as without properly defining this, your system would just be a glorified database.
That’s a genuinely imviessrpe answer.
Thank you, Dayana 🙂