How to measure improvements brought by our Incident Mgt project (3).
MEASURE 3: Market Share
Definition:
Number of user calls recorded per user per month.
What's the use?
I am not sure that "Market Share" is a very good name for this. Does anybody know another way to call it? Anyway, here's what it is good at: this gives you an idea whether 1st level support is doing one of their key tasks, which is... recording calls! Although it can sound obvious that 1st level support should record all calls, as an analyst, if this is not made very clear by management (and supervisors), it is very easy to slip away from it. Ex: "The user called and I solved her problem in 30 secs. Why would I record that? What's the use? It will take me more time to record it than it took me to resolve it!" It is not uncommun for an analyst to prefer to be the "hero" who solves 10 things like a Superman, than solving these 10, and recording what you have done. What extra reward do you get from recording that?
That's when this measure comes in handy. I've been told that industry average for recording calls should be roughly 1.1 record / user / month. Of course it varies a lot from one industry to another. And whether you have a majority of plant workers, or a huge marketing team ;-) But that can give you some idea where you're at with this activity.
Limitations with this measure
The objective is not to record more calls than there really is, to have nice numbers. Actually, if we had very good problem management, change management, availability and capacity management, etc, we should not have so many Incidents no? Still, if your company is big enough, you may be able to use this measure to highlight which L1 support team is not doing that part of their job properly. And believe me, at my place, it is quite obvious.
Another limitation is that it is not taking into account the quality of calls recorded... this would require a softer measure.
MEASURE 3: Market Share
Definition:
Number of user calls recorded per user per month.
What's the use?
I am not sure that "Market Share" is a very good name for this. Does anybody know another way to call it? Anyway, here's what it is good at: this gives you an idea whether 1st level support is doing one of their key tasks, which is... recording calls! Although it can sound obvious that 1st level support should record all calls, as an analyst, if this is not made very clear by management (and supervisors), it is very easy to slip away from it. Ex: "The user called and I solved her problem in 30 secs. Why would I record that? What's the use? It will take me more time to record it than it took me to resolve it!" It is not uncommun for an analyst to prefer to be the "hero" who solves 10 things like a Superman, than solving these 10, and recording what you have done. What extra reward do you get from recording that?
That's when this measure comes in handy. I've been told that industry average for recording calls should be roughly 1.1 record / user / month. Of course it varies a lot from one industry to another. And whether you have a majority of plant workers, or a huge marketing team ;-) But that can give you some idea where you're at with this activity.
Limitations with this measure
The objective is not to record more calls than there really is, to have nice numbers. Actually, if we had very good problem management, change management, availability and capacity management, etc, we should not have so many Incidents no? Still, if your company is big enough, you may be able to use this measure to highlight which L1 support team is not doing that part of their job properly. And believe me, at my place, it is quite obvious.
Another limitation is that it is not taking into account the quality of calls recorded... this would require a softer measure.
posted by ITIL Project Manager at
1:04 PM
7 Comments:
This sounds like a "Lets shoot myself in the foot" measure.
Too high and it looks like your product is of poor quality, too low looks like the incidents are not being recorded or you have too many staff (not sure if the number of staff effect this measure).
Do you have some sort of IVR or system that can record the number of incoming calls to your help desk?
Comparing that to the number of incidents recorded would maybe be better.
I've experiences a scorecard where the measures drove behaviours opposite of what was required.
Measuring issues queued to technicians but not issues answered immediately by the technicians. Read it incorrectly and it looks like to keep the number down you need more technicians.
Or my favourite, keep the length of calls short. Look like you are going to blow your daily average? Just hang up on the next few callers. Quality control? they are looking at that measure next month. (I'm not saying this happens, just it could)
Steve
By
Anonymous, at 9:10 PM
Steve, I think you are correct to some extent: this is not the greatest measure to use to set targets. I would rather use it to identify where we have weaknesses in Incident recording, then handle the issues using "soft" human interaction rather that "hard" scorecard/personnal objectives.
Anyway, knowing we do not have any kind of IVR or similar system, would you have an other idea of a similar measure we could use to measure if analysts are recording the calls at all?
Xitil.
By
ITIL Project Manager, at 10:37 PM
Then this gets tricky. Difficult to drive what you can't measure.
Possibly supplement your measure with other data. Ask the analysts for a daily or weekly estimate of how many calls they take? and or run some kind of comp as part of the introduction for the number and quality of the recorded incidents. This will only give you some kind of indicator for the current position. Your existing analysis would probably be just as good.
Steve
By
Anonymous, at 4:16 PM
What may be more useful is to have your 1st line HD staff keep a tally sheet of how many calls they take from users who have had their incident resolved by one of your 'superman' techs in 30 seconds only to have follow up issues as a result. If your system lets you easily check previous calls for the user and they are able to tell you that so-and-so fixed xyz this will be a useful indicator.
Do you have self-service for users yet? Allowing them to log their own calls helps on both sides as the techs just need to resolve the calls and the users know they have logged the issue and can track it.
If you haven't got it already, I'd recommend you get a cop yof: Metrics for IT service management ISBN: 9077212698
It has some good guidance on just the sort of thing you are addressing currently in your blog.
By
The ITIL Imp, at 2:27 PM
Thanks all for your recommendations. Actually, one of the next initiatives of our project is to allow users to record Incidents or Requests themselves if they wish so. One of my colleague raised the question of quality of the logged call, when recorded by the user directly. How do you manage fact that you'll get number of calls such as "My application does not work anymore, please help me." Will that really contribute to resolving the Incident any faster? One of the idea is to ony let them report very specific, pre-defined calls like "My keyboard is not working anymore" ;-)
By
ITIL Project Manager, at 3:13 PM
Hi there,
Depending on the software you are using you can do exactly that, create 'templates' such as:
My X doesn't work... and select the bit of hardware.
I've forgotten my password.
I'm locked out of Y.
etc.
In our case we use a customer set of categories as a substitute for the templates and the user can enter: a call title, a description of the problem, and choose what they think they priority of the call is. When they confirm the call and are issued with the call reference; the call is automatically assigned to the Help Desk team.
At this stage that they do the quality checking (if necessary put it into english or call the user back for further infomation). The call is only assigned to a support team when the completion of other fields (the customer category automatically maps onto our opening call catgegories where appropriate) and quality check is finished.
Of course, you've still go the issue of a HD manager quality checking the calls that the HD operators put through - but it ensures that no non-sensical calls get to a techie from a user.
Look forward to your next post.
By
The ITIL Imp, at 1:06 PM
As we get started with ITIL in my school district, one of the first steps we're taking is creating a Service Desk - right now incidents are self-recorded by users via a web page and techs show up eventually to fix the problem. Not very ITIL-like :)
I've given thought on how to measure performance of the Service Desk, and one of the ideas I came up with matches nicely with the first comment here - match up inbound calls to incident records. If there's a gap, some calls did not get logged.
I'm glad I found your site - I just created the same sort of site to document our experience in implementing ITIL-based processes. I'll be adding yours to my Bloglines :) Good luck to you!
By
Anonymous, at 10:17 PM
Post a Comment
<< Home