SLA Rule Perspectives & HR Service Delivery – Part Two
My fellow colleague Dwane Lay recently wrote a blog entry regarding Service Level Agreements (SLA’s) and how we both have slight different views on SLA’s in relation to Case Management.
What does SLA actually mean?
Firstly if we step back and ask ourselves “what do we actually mean by the term SLA?” I often hear people speak of an SLA as simply an amount of time a Service Provider has to respond or provide a resolution for a Customer issue; although these are components of an SLA, this is not a true definition of one. An SLA is much more than this!
An SLA is an agreement between two parties, that describes the service provided, documents the Service Level Targets (what the service will be measured against, think KPI’s), and specifies the responsibilities of the Service Provider (HR in our case) and the Customer (Employees and Managers).
SLA’s and Case Management tools
When you bring SLA’s into Case Management tools, you typically see a range of SLA’s implemented based on a number of factors such as; how important the issue is to resolve, and how much impact does the issue have on the business. Within each SLA you would normally define the initial response time and expected resolution time for a given SLA.
Initial Response Time is the time it takes for the Service Provider to make the first contact with the customer after the issue has been identified by the customer or the service provider.
Expected Resolution Time is the time taken to resolve the issue within an agreed time schedule, calculated at the moment the issue was identified by the customer or by the service provider. Think of time schedules as a business support calendar, for example: Monday to Friday 9am-5pm might be the supported hours of the Service Provider.
A common target for a Service Provider is to achieve 95% of the initial response and expected resolution times.
As the user of the Case Management tool and Service Provider to the SLA’s you would determine what constitutes a high priority issue versus a low priority issue, or what issue should have a more stricter SLA than another, this would then be agreed upon in the actual Service Level Agreement document. A feature of a modern HR Case Management tool is that they are flexible and adaptable to meet the requirements of each company’s own SLA requirements.
Example time
Let’s do an example: a priority 1 issue might have an SLA assigned that has an Initial Response time of 1 hour with an expected resolution time of 4 hours. Whereas a priority 2 issue might have an SLA assigned that has an initial response time of 2 hours with an expected resolution time of 8 hours.
Now, looking back at my colleagues recent post which was focusing on one particular conundrum of SLA Management. Which was: what to do with the SLA when an Issue is escalated or downgraded in priority?
Lets say our priority 1, after 30 minutes is considered no longer to be a priority 1 (for whatever reason), and is now downgraded to a priority 2. The standard approach here is to either restart the response and resolution times as defined in the priority 2 linked SLA, or to take away the spent time from the new allowances defined in the priority 2 linked SLA..
In the first example, the downgraded case would reset to priority 2 and its linked SLA, which results in a new 2 hour response time and an 8 hour expected resolution time being provided.
The second example would see the original 30 minutes spent time, being subtracted from the new priority 2 linked SLA, in our example this would result in 1.5 hrs response time remaining, and 7.5 hours left to provide a resolution.
Downgrading is rather simple and as shown either of these examples would work well, it is when you escalate a priority you should keep to one practice only. Lets look at an escalation example next.
Example:- a case is logged and assigned a priority 2, therefore there are 2 hours to respond and 8 hours to resolve the issue. After 30 minutes has passed, it becomes clear this issue is in fact a priority 1 case, and not priority 2. Again, this could be for any number of reasons, not just the service team accidentally selected the wrong priority.
Best practice here, when escalating, is to reset the SLA allowance, and provide the full time of the new SLA, which in our example would be 1 hours to respond and 4 hours to provide a resolution.
Why?
Many reasons why:
Number 1 – Agreed Framework
The original Service Level Agreement typically has a clear statement held within its framework that states that SLA response and resolution times are measured when the issue was identified and classified by the customer or service provider.
Remember, the SLA is an agreement between both parties, it should not be one sided.
Also recall the definitions of Response Time and Expected Resolution Time, they are both calculated from the point in time when either the customer or the service provider identify the issue – since the issue has been escalated based on new information, and must be treated as such.
Number 2 – Separate Teams Handling Issues
Escalated cases, in our example, priority 1, might be handled by a separate team. This team will require the full SLA to maintain their SLA targets and the department SLA targets.
Number 3 – Don’t set yourself up to fail!
The HR Service Centre will find it very hard to meet their SLA targets if issues are escalated, and elapsed time is taken away from the new SLA allowance. Especially if 4 hours had been spent at priority 2, then the escalation would force an automatic SLA breach – you are setting yourself up to fail!
Remember, the SLA is an agreement between both parties, it should not be one sided.
Number 4 – Issues Escalate based on new Information
The original assignment of priority 2 was valid at the time of given information, only after additional research or information was the issue in question identified as a priority 1, thus the issue begins the Priority 1 SLA time allowance.
Recall the definitions of Response Time and Expected Resolution Time, they are both calculated from the point in time when either the customer or the service provider identify the issue – since the issue has been escalated based on new information, and must be treated as such.
Number 5 – Issue created via Email or Self Service with little information provided
The Employee may well have not provided enough information when the issue was originally reported to the HR Service Delivery team – perhaps the Employee sent the issue in via an Email or Self Service. Only when a Service Delivery Team member looks at the issue do they recognise and classify a higher priority issue. This would then result in the HR Service team having less time to resolve the issue, and would results in over complex SLA rules that are not consistent with how the issue was reported on – they should always be consistent!
Any Concerns here?
The one area of concern that often comes up in discussion with this practice is the loophole that users of the system can find, by manipulating the SLA against the issue they can effectively buy themselves additional time, and alter the HR Service Delivery SLA Performance Stats. To manage this, a simple report should be created and monitored to spot trends in user activity and necessary follow up action taken. An alternative here is to have event triggered rules that fire a notification to a team leader when events like this occur.
Summary
In summary we need to remember what the SLA actually is. It’s an agreement between the HR department and the rest of the business. Departments within a firm are not looking for HR to fail, so by sticking to the advice above you will end up with the Best Practice method for SLA Management, and set yourself up for the most attainable HR Service Delivery SLA Performance Metrics possible.
