First of all, what does it mean to have received 500 calls in a fortnight? OK, you can benchmark it and compare it to averages with other similar organizations. But still, it does not mean that much to me. It might just mean that your users are not that IT savvy and there is a culture to call the help desk as soon as something unexpected occurs. By itself interesting insight and you might want to change the culture of the organisation.
Secondly, does it mean that your services have degraded if the number of calls have risen in the last three months? You might have rolled out a new system and the increase in calls can therefore be expected. Or the increase in calls was caused by a significant staff turnover in the last period.
If you have rolled out a new system and you can expect the number of calls to increase. In such a case the stats are not a direct measure of the helpdesk and in the early stages relate to the effectiveness of the project. Because you will run in many teething problems and the fact that the helpdesk also needs to build up experience, many of those calls have to be redirected to the second level support and to the engineers. The first line helpdesk team has quite often no direct means to resolve these.
And think about this. If you roll out a new system and you do not receive many service calls, would that be because the system works fine and users are using it effectively or because they are not using it? And when you are receiving many calls, can it be because the users are very keen on using the system and are going through a steep learning curve and therefore log many calls?
In the past I inherited a few systems that were rather instable and regularly went down and threw up java errors. The systems had many bugs and the effect was that we spent most of our time fighting fire. Over time we improved the stability and our development practices. Some of the systems were rebuilt from scratch. The end result is that those systems are stable and basically we don’t receive any calls around problems with the system. We do receive calls in relation to new functionality and that is where we want to be. Spend our time on improving the business with new features instead of fixing bugs and restarting servers. The effect can be seen in the statistics in our helpdesk system but they can only be seen over a longer period of time stretching years.
The calls that come in relation to those systems are not going to be dealt with straight away. We plan this in our development process and prioritise them with our customer. It means that some of those requests stay open for a longer period of time. Basically they are not really helpdesk requests but we use the same system for it.
If you want to measure the effectiveness of the helpdesk itself, you can only look at those calls that fall in a category where there is stability and where it is expected that the helpdesk actually can resolve the calls. Proper classification of received calls is crucial to any reporting.
There is a difference in the role of the helpdesk in case you have a small set of business systems with a large number of users or when you have a large number of business systems with each a small number of users.
I had the pleasure to contact my ISP because my ADSL line was regularly dropping out. The ISP provides a standard service to a very large number of customers. The helpdesk has been provided with a script of questions and steps to go through to resolve the problem. In such a scenario this is very well possible and you can resolve this way the majority of calls. (Though in this case it was driving me crazy; needed to call many times and each time you get another person who wants to start the whole thing from scratch.)
But the scenario of the ISP is rather different then we have in our work situation where we have a relative large number of business systems with each a relative small number of users (excluding our real external customers for which we don't give helpdesk support through our IT department).
I have my doubts on just reporting helpdesk statistics as a KPI and I think you should be cautious reporting those numbers as the performance of the IT department to your customers and senior management. The numbers can be valuable if you actually analyse the cause, draw consequences and take measures for those causes within your own control. But without an explanation, the numbers can give a wrong impression of what really goes on.
I am not saying that you should not do the measurements. Of course you need the numbers for a variety of reasons and you still need to address the cause of increases of service calls and understand why it happened. Another reason is to manage your workload.
I am more keen on using surveys to identify effectiveness of the IT services as Gus also reports and using the Service Level Effectiveness as per Gartner’s Business Value Model
Service-Level Effectiveness = Surveyed users with >=90% satisfaction/Total No of surveyed users
This measures all aspects of the services including, and most importantly, the actual user experience. For example, when you just rolled out a new system and have a high level of service calls, the users still can be satisfied with the service (they love the system and the helpdesk provides great assistance). Or it could be completely the other way around, only a few service calls but low customer satisfaction.
