Identifying why a request was not resolved on time is always a difficult task. Whenever the SLAs are in red or our customer satisfaction ratings are low, a brave soul must search for the reason in comments, status changes, and the activity / audit history of the extensive request.
The simple fact of analyzing unstructured information makes this a difficult task, which easily puts one in a bad mood. To make matters worse, the results of these analyses are often not clear or precise, and usually end up wrongfully putting the blame on the customer.
In this article, we'll show you some tips so you can identify where the ball was and thus understand and correct the delays in future incidents and service requests.
Monitor, measure, correct
The aim of all help desks is always to improve customer service and reduce times. Failure to comply with a deadline set for the resolution of an incident or service request usually is directly associated with a task or action that took longer than it should. Now, how do you know what task was delayed? Where is the brave soul willing to search for the reason? There’s no need for him at this point in time. You can identify these delays and bad resolution times without him. To identify where the ball is at, it is necessary to have visibility over each period of time that elapses in an request, and differentiate between types of wait times. With this data you can measure the distribution of delay in a particular request, draw conclusions, and make correct decisions as needed.
The ball and the player
If the incident or service request were a football soccer match, the location of the ball would indicate who must act in order for the game to go on. The players would be the participants in the request, and each player would pass the ball during the entire game. The player in possession of the ball determines what comes next. If we were to time the ball possession of each player, we would know who had the majority of the responsibility; and if there were delays, we could ask them why.
The Guilty One
Imagine that one of your customers creates an incident reporting a service interruption in sending emails. Once your technical team performs the analysis, it identifies that the cloud provider is having a problem with one of its servers that is affecting the emails of the customer’s company. Now one of your agents must file an incident to the provider and wait for news. Days go by and the SLA of the original request expires. Later, the problem is resolved and the customer is notified that the service has been restored, and that the delay was due to a problem with an external entity. However, the customer completes a customer satisfaction survey for this request, and provides a poor rating because the problem was not resolved in the allotted time. Sounds familiar, doesn’t it? What should be done to understand what happened with this incident, its expired SLA, and the bad customer satisfaction rating? If you had the ability to identify where the ball was at every moment of “the match”, you could very easily understand what happened and act accordingly; in this case, talk to the provider or reset expectations with the customer.
The issue could be the customer, another request, an external entity, a “wait until” date, the assigned agent, or something else; but it is critical to take the time to identify where the ball is at in order to understand what has happened and what is currently happening.
Not utilizing this type of feature results in reviewing the entire history of the request to understand what went wrong. Knowing where the ball is will save time, frustration, and will give you the opportunity to make corrections at the right moment; as would have been the case of the external provider in the scenario above. To have this clear picture of who has the ball is a significant factor in providing proactive support, as well as making on time decisions to get ahead of your potential problems.
Don’t get nutmeg’ed in your game of IT service management.