Read more: |
Matti Grönroos
Do the Quality and Number of Tickets Correlate?
Anyone who has ever managed IT service production understands the insanity of such an order.
The number of tickets and changes in them are good indicators of many things. But does a drop in the number of tickets imply that the quality has improved.
Well. Most probably the answer is simple: No.
Perhaps the most common reason is a major change in the application portfolio: New applications, new versions, new functionality. In such cases, users tend to run into trouble, which the service desk helps to solve. In general, all major changes tend to cause the number of tickets to peak.
Such changes usually are business decisions on the customer side. Changes in the number of tickets are far beyond the capabilities of the service provider.
What is interesting is where is the point where the user raises a ticket instead of trying to solve an issue.
The experience of the previous cases is the key point here. If he or she was served by a rude or a clueless person giving no useful help, most probably bypassing the official support channel is the first choice. Instead, the colleagues might be able to help, or their people networks. A Shadow IS/IT was born: just something that the existence of a service desk aims to prevent from happening.
It is largely the same as in any business: Good experiences lower the threshold to do business with the same shop again and the bad ones raise.
So, the most certain way to reduce the number of incident tickets is to produce very bad user experieence, and spread this reputation among users.
The correlation between the number of tickets and the quality of the service may therefore work exactly the opposite of what has been thought.
Even if you don't go to this extreme, it's good to note one thing: As an indicator, the number of tickets subject to manipulation. The boundary line between incident and service request is not crystal clear. For example, "I cannot access my service be I have lost my password" may be interpreted as an incident. However, "Please reset my password to my service" is a service request. What the user wants is the same. If a service provider is sanctioned for an excessive number of incident tickets, but is thanked for fulfilling service requests, the temptation to record incidents as service requests easily arises. This leads to the loss of the big picture. In addition, it might be the way to manipulate the time-to-resolve metric of Incident Management.