In many organizations providing proper status information in the process of solving IT issues seem like quite an issue itself. No matter how it is or isn’t provided, the users are always unhappy about it.
It departments make many mistakes about providing proper status information. The worst approach is no info at all. Users report an issue to the Helpdesk team and they receive no information until the ticket is solved. They are telling the support team that something is wrong and have no feedback if anyone is doing anything about it.
To address this issue, an ITSM system is implemented and the automated module steps in, sending users information every time a ticket has its status changed, is reassigned or any other detail of it is modified. It seems that users should be pleased that they have information about every change of their issue. But they’re not. They are rather frustrated with being spammed with multiple e-mail messages before anyone even starts helping them. What’s worse the information is not only meaningless to them but also is provided in a kind of ITIL jargon, which they don’t fully understand. As a result, it makes them feel helpless and stupid.
So, is there a way to make the users happy about it?
Why providing status information is so important?
Let’s start with the basics. As users complain when there is no information provided while solving issues, it seems to be important for the users to have this information given to them. But why? Can’t they just wait and let the support teams do their job?
It may sound like to deep analysis, but it comes down to a people’s psyche. People are naturally afraid of the unknown. When we’ve been living in caves or on trees, everyone who hadn’t been worrying about the unknown was killed by some kind of predator or hostile tribe member after thoughtlessly walking into the jungle. As a result, through evolution, the fear of the unknown has been developed. It started however to have interesting side effects. Without cautiously verifying what indeed is down in the unknown, people started to fear everything that potentially might be there before even checking. While the caveman is sitting in his cave, his imagination would give him not only the worst possible version of what’s out there but all the worst versions. For the caveman, it would be all potential predators attacking them all at the same time. In the situation of our user waiting for his or her issue to be solved, the worst versions are that his or her issue has been forgotten, has extremely low priority, and/or is waiting in a long queue of similarly low priority tickets. If the user is prone to negative thoughts, he or she may even suspect that the support team actively sabotages his or her case. These kinds of scenarios developing in minds of users left without any information, generate growing frustration. Obviously, this frustration doesn’t improve the users’ perception of the quality of the IT Department’s services. That’s why they’re complaining.
Ways of providing status information – the wrong way.
Even the worst, but the known scenario is much better than all possible worst scenarios imagined by a mind left without any information. If the ticket is indeed a low priority issue and it’s still waiting in a queue due to a very high number of submitted issues, the situation can be improved just by providing proper status information.
Let’s try out a different strategy on our caveman. Let’s provide him with a lot of details to ensure him what indeed is going on around… And as an equivalent of the job the user has to do while his or her issue is being solved do, let’s give this information to our caveman while he tries to light a campfire. Let’s tell him that there are five black ticks on particular trees around the cave, that the lion female of about 4 years of age is 5 miles from him, heading southwest with the speed of 3 miles an hour, and that there is a 6 feet long snake with yellow eyes laying 7 miles from him in a north direction, and so on, and so on… These all pieces of information seem very important for a caveman from our point of view. But is it really useful for him, while he currently stopped worrying about the threats outside and tries so hard to start the damn fire? The only thing he needs to know at that moment is if there is any threat approaching the cave directly. Everything else just distracts him from his job… The job that may potentially save him from a predator when it indeed comes close to him. The same way that multiple e-mail messages with meaningless information distract the busy user. As they don’t give the user much value, it only makes him or her nervous by wasting their time already impacted by the reported issue.
So what the user really needs to know and how the information could be served to suit him or her?
How to provide the status info properly?
First of all, no matter how loudly users complain about the overwhelming amount of messages from the ITSM system, the information should be provided. Badly delivered information is always better than no information. So how the information should be provided? Unfortunately, it depends on many things, but mainly on the perception of the user about the complexity of the task to be fulfilled and, as a result of that, about the expected time for the issue to be resolved.
Confront the user with reality as soon as possible.
What should be sorted out at the beginning of the ticket live is facing the user’s expectation with the reality of possible time needed for the solution. It’s much better for the user to be disappointed at the beginning of the process, by being informed that it will take 3 days instead of the expected 3 hours, than to be frustrated by 6 hours of waiting for something, which he expected to be solved within 3 hours, and then getting the information that it will take another 2 days. The reality he or she is facing is exactly the same, but the emotional reaction may be different based just on the timing of delivering bad news.
OK, so the user knows how long it will take to solve his or her issue. What now?
Make the info as accessible as possible.
As mentioned at the beginning of an article, the biggest fear of the user is if anyone is even working on the ticket. This fear should be addressed in a meaningful way. How often should the information be provided? Perfectly – when the user needs it. Unfortunately, it’s not possible yet to read in the users’ minds, so it has to be accomplished the other way. The user needs to have this information at hand every time he or she needs it. In other words, it has to be accessible to the user as easily as possible. Every non-disturbing way of providing it would be very welcome. The direct link in the e-mail message about opening the ticket is a must but not enough. A quick launch agent giving access to this information with 2 clicks is a good approach for example. It’s worth spending some time considering the ways to do it. But is this enough?
Provide the info with the right timing.
Well, unfortunately, no. The user still needs to be informed proactively about the progress. Why? Because it makes the user feel more taken care of in a stressful situation of suffering from an IT issue. How often should the information be provided? It depends highly on the expected time of the issue resolution. If it’s a simple case, some users would expect information about the progress every 10 minutes. If the issue is more complex and is expected to be solved in 2 weeks, providing the status to the user every hour would be way too often. Generally speaking, for the issues of medium complexity, delivering information 2 times per day seems like a good compromise.
Make the info understandable.
It is important how often the information is provided, but what’s even more crucial is the way it is delivered. As described before, telling users about every change of the status of the issue in the ITIL jargon generates their negative emotional response. Summarization of the activities which happened since the last update with some very short explanation of what it means and why these steps were taken seems much more efficient. If the user not only knows what’s happening but also understands the meaning of it, he or she feels much calmer. So again, is this enough? Usually yes, but you go beyond that.
Recognize their feelings.
If the user understands the meaning of the status messages, it’s a great deal for the IT team. If the user feels understood in the situation, however, that brings the communication process to a whole different level. Phrases like “you may feel frustrated” or “you may think that solving this case takes way too long” may seem very counterintuitive – like you’re trying to put bad feelings into the users’ brains and hearts. In fact, however, this kind of communication dissipates bad feelings. Many people would instantly think “no, I don’t think/don’t feel that” even if they are really starting to be a bit nervous. Recognizing the users’ negative feelings can only improve communication in the process of solving an issue.
Why support teams don’t provide proper status information while solving tickets?
OK, so what’s needed is not too much, no too little information, provided as a summarization in an understandable way with a little bit of empathy. Doesn’t seem like rocket science, does it? If so, why so few IT teams do it properly?
First of all, it’s much easier to say it than to do it. As explained above, adjusting the frequency of the communication may vary depending not only on which user is affected but also on the current emotional state of the user. The same user may react differently according to his or her current mood. It generates a number of issues when providing status information.
Automation of providing the status info.
Until an advanced artificial intelligence is developed to sense people’s emotions, it is very hard to automate the process to fit each case at least in a good way. Not only adjusting the frequency gets challenging in this case. Formulating automatically an appropriate summary, which would feel like something really put together in a logical way, not just a collection of separated statuses from the ITSM system, needs some advanced development to sound convincing. Adding some empathy in a way looking like something more real than a random “empathic” sentence added to the message, can be quite challenging too. In other words, it is not easy to automate providing really valuable status information.
Who should provide the proper status information?
The only solution left is to have it provided by real people. The challenge with this option is of course the cost. Putting additional effort to fulfill the tasks of appropriate communication to every ticket may not be acceptable for the management. In many organizations, there is however a role dedicated to preparing and providing proper status updates to the affected users. It’s the Major Incident Manager. Unfortunately, employees holding this role are dedicated only to performing the communication job for high-priority issues. For the rest of the cases, giving the status updates is automated in the ITSM system or left in the hands of the Helpdesk team together with other support teams solving the issue.
Here comes another challenge to provide the status information properly. As described in the article Are Helpdesk Teams Doomed to Lose Their Best Employees? , Helpdesk staff are usually not very experienced and business-aware employees. They are often not trained enough not only to provide the proper status update but even to fully understand the importance of doing it. As you can read in the article The First Line of Helpdesk – Global vs. Local, the Helpdesk service KPIs also usually don’t support providing high-quality information. The only exception is the “users’ satisfaction survey” KPI, which shows a sum of many aspects of the Helpdesk service and is quite hard to analyze. In many cases, not enough consideration is put to review it in order to really make valuable conclusions about the quality of the communication. In the end, however, all of these aspects come to the costs of work time needed to prepare adequate communication for every ticket. Most organizations are not ready to bear this cost or don’t see a sufficient return of paying it.
What to do about it?
The absolute minimum is providing communication training for all of the IT employees having business interactions with the users. Especially Helpdesk staff should regularly be trained in the area of effective and empathetic communication. Hiring Major Incidents Managers and assigning them to the biggest possible scope of issues may be useful too. It has a financial limitation, but if this option is available in the organization it would be a big mistake not to take an advantage of it. The MIMs also need to have their communication skills sharpened regularly. The other thing to check is if the ITSM system used in the organization allows adjusting the amount of communication provided. If yes, it would be useful to inform users that they can tune how many messages they want to receive about their tickets. Even if they don’t change any setting, the possibility of doing it will make them feel better about an overwhelming amount of e-mail messages.
Summary
As you can see, many challenges need to be solved for users to really feel satisfied with the status information provided while solving their issues. Some of the problems are quite hard to overcome, others take too much money for the management to sponsor it. As a result, doing it properly is much harder than it seems. IT managers should still try as hard as they can to improve the quality of communication in every area of interaction with users. Putting constant effort into improving the communication between the IT team and the users has a great potential to improve the IT department’s visibility in the organization.
Photo by Direct Media on StockSnap
