Page 1 of 1
Posted: Wed Dec 17, 2014 1:54 pm
What should be the average Time to Resolve for requests made to the Help Desk (where the Help Desk owns the ticket)? There is Level 2 and Level 3 support (who have their own issues)....
I think I may be walking in to a mine field...I may become the new Help Desk supervisor for this organization and as of today they have felt this metric is best represented in....DAYS!!!
Posted: Thu Dec 18, 2014 6:39 am
The answer: Our business measures IT performance for Service Desks and provides monthly reports to our clients with their performance vs industry. (simplr.it). Based on our data (and assuming you're talking about Incident records only) our data shows that the average age of tickets resolved at first level is less than one day. BUT....
This metric is not worth measuring. It's interesting, and it seems to point to some sort of "performance" based measure, but as a manager of a support team you need to maintain low costs while providing high customer sat. These are your two focuses. Therefore it's most important to understand what drives low cost, and what drives high customer sat. This metric does neither.
Businesses want to measure a range of metrics, often far-flung metrics that don't add much value to your understanding of performance.
My guess is that they see this as a customer satisfaction (CS) driver? If it is to measure CS and your first contact resolution is below 80% then don't waste your time. You will get better value for your effort (and your IT spend) by focusing on increasing first contact.
There is an epidemic failure within Service Operations to over-measure metrics without any clear understanding of the reasons of doing so. Doing this clouds your thinking and hurts performance.
Try this... Measure three categories:
1. Cost (Cost per resolution / First level resolution)
2. Customer Satisfaction (CS, First contact resolution, Average resolution time outside of Service Desk)
3. Productivity (Analyst utilisation at Service Desk, Resolutions per person outside of Service Desk)
These three categories provide more than 80% of the value for effort within IT. If the sub-metrics are performing well then you will be delivering outstanding service and will never need to look at it.
Posted: Thu Dec 18, 2014 1:41 pm
Great answer simplr!
I heard a great podcast from Pink Elephant a few moons ago that (i'm in agreement with) that FCR should not be a guiding metric (it's not a bad one - just not one to ascertain value on your Help Desk) - putting too much value in to FCR might just mean that your Help Desk is really good at 'fixing' issues that are occurring too often! (Where Problem Management may need to step in)
I expect my Help Desk to be quick to contact customers (2/3's of our tickets are via email) and resolve issues within their scope and if they are unable to do so then to forward the incident to the next level. I don't believe a Help Desk should ever have an incident for longer than a day - realistically I would like the incident resolved or forwarded within 2 hours.
Currently...and I gulp every time I see this...the Help Desk has an average Time to Completion of.....18 days....
Now with that said...there is no formal ITSM framework implemented which is why they are bringing me on. I was just shocked when I saw the Help Desk number!
Posted: Thu Dec 18, 2014 4:35 pm
1) Customer satisfaction is what tells you about the quality of your support. This is the guiding metric, whereas FCR is the driving metric (e.g. it drives CS heavily). Is that what you're saying?
2) I'm not 100% sure you should take the 2 hour approach you mention below, purely because it would be easy to create a behaviour that impacts the second key metric (Cost). Keep in mind that first level resolution is one of the key drivers for cost. And you don't want to add 1 point to your customer satisfaction at the cost of 10 points to your cost.
We worked with a client recently who had a service desk of 58 staff, and 140~ L2 & L3 staff. The Service Desk were given a timeframe of 15 minutes to resolve a ticket on first contact and 1 day to resolve the ticket. After this point they had to escalate to L2.
FCR was around 45%, FLR was around 55%, and calls answered within 30 seconds was around 90%. The business mistakenly believed that answer the call quickly was what drove CS (which incidentally was at around 35%).
On day three of working with this client we removed the 15 minute and 1 day restrictions. Calls answered within 30 second went down to about 80%, but FCR went up to above 75% and FLR went up to above 85%. This resulted in over ~4000 fewer tickets (or ~40%) being assigned to L2/L3 per month. This also decreased calls from customers by over 150 per week (which we put down to a reduction in follow up calls).
These types of restrictions can heavily impact your cost and CS. After 3 months with this business they had removed 8 contractors from the SD (roughly $450kp/a cost to the business) and 17 L2 contractors from the business (1.6m p/a cost to the business). They were resolving more on FCR & at FLR, and had increased their CS to above 50% for the first time in 6 years.
Moral of the story, one or two procedures that drive undesired behaviour can result in millions of dollars cost to the business without the customer seeing any value.
3) 18 days.... it'd bet my house that it's a process issue as opposed to a performance issue. That figure would have to be made up of extremely aged tickets. And it's likely that the missing step in the 'process' is that the manager is measuring aged tickets, or misunderstanding why we measure aged tickets. The reasons for measuring aged tickets is to identify process flaws - e.g. if a ticket is 50 days old then it should have been escalated to the manager to address long ago, and to enable a manager to create time for their staff to resolve these. These tickets are often in limbo and you don't necessarily need a tech person to resolve them, generally it's about a good problem solver working through the issue (read Back of A Napkin for help here).
.... one day I'll write a short post - I'm sure of it!
Posted: Fri Dec 19, 2014 10:56 am
I typed incorrectly - I meant my 2 hour time frame was for first contact - but I agree with your #2 statement nonetheless.
To be fair at my previous Help Desk stop 90%-95% of our customer 'events' (service request or incidents) was via the phone. My current organization has 2/3 of their 'events' occur via email. I don't have a lot of experience with a good metric for first contact through this mode - so perhaps I should just drop the 2 hour first contact and just stick with a one day resolution or escalation?
You also bring up, I believe, the quintessential problem that is facing my Help Desk and IT organization - they either have no processes or flawed processes.
There are currently no metrics being measured, no SLA's implemented, literally there is no framework in place. For the last (I can't even be for sure) XX years the department has been a reactive, 'I'll work on it when I can', 'no accountability' chaotic type of technical group. No synergy, no communication between groups...you get the point. And all of this, sadly, falls back on the customer and their (lack of) satisfaction.
It's going to be a culture shock but with the upper management's support and backing I think we can get on track. I think the best place to start is the Help Desk.
Thanks for the book recommendation!
Posted: Fri Dec 19, 2014 9:22 pm
It sounds like a dream assignment for you. I love it when nothing is in place and nothing (or the wrong things) are being measured because you make make huge improvements within a very short time. Just make sure you get the baseline and you'll be able to show massive improvement in no time at all.
Re FCR - We measure this as 'resolved within an hour' of the ticket being opened. I find this to be more closely aligned to true CS than just on the first phone contact as many companies measure. When you think about yourself as a customer, if you call a help desk you just want quick resolution. Anything that gets resolved within an hour for me is pretty good ( depending on the situation of course ). The only other thing to keep in mind is the lag time between arrival and logging. For this I will get the manager to do a spot check of 15 - 25 tickets every couple of months to determine average lag time. We can then factor that in.
If you like, go to simplr.it/reporting and signup. Its a tool we use for initial tracking / baselining of our clients. The data entry is manual at present but it will graph out some of the most important measures. There are 'Create daily report' and a Create monthly report' options where you can enter this data.
The software is by no means full featured, but it is something we're using to help clients focus on the right metrics. We're also providing benchmarking comparisons for clients so they can view their performance vs. industry and this is how we currently collect the data.
If you run into any issues let me know - it's something I'm working on improving in my spare time.
Posted: Wed Dec 31, 2014 1:28 pm
Thank you for the link to your site. I will give it a whirl.
Yes, a dream assignment - the work itself is going to be very exciting. The baseline numbers I am getting are certainly going to be eye opening to upper management but implementing just a few simple processes will show incredible improvement.
To be perfectly honest I have no issues with implementing the framework itself - upper management is not only on board but has a firm understanding of the outcomes and how we are to proceed.
The biggest obstacles will be the culture change. Some of the folks here have been doing just fine by doing just what they need to in order to get by. They do well enough on their annual reviews (although those reviews don't really measure or evaluate anything in terms of IT) and they don't see a problem, so why change?
Well, numbers don't lie. And once I start getting those pre-implementation customer service/satisfaction surveys back I should be able to paint the whole story - My baseline numbers will show what has been going on within IT and the survey should show the perception outside of IT.