For starters, I have some bad news for everyone. Software bugs do and will happen. Despite the fact that programmers are cordoned off by testers, and applications are scanned with automatic tests from A to Z, it can always happen that a mouse slips through. As history shows, sometimes it is a whole horde of mice, which was experienced by Cyberpunk 2077 users not so long ago. Sometimes it is one, fat and extremely expensive mouse. I mean the case of the NASA Mars Climate Orbiter probe, which in 1999, as a result of a rather prosaic error – inconsistency of the units used in the flight trajectory calculation – was destroyed in the Martian atmosphere. Almost 330 million dollars evaporated along with the probe, which is how much the entire mission cost.
But there is also some good news. Each company that provides software is deeply concerned about the fastest and most effective correction of any error reported by the application users. There are several reasons for this approach. The most obvious and probably the most important is the desire to have satisfied customers. It is them who, by sharing their opinions and thoughts, have a great influence on how a given application is perceived on the market, which in turn influences the purchasing decisions of potential users, i.e. whether the software supplier will earn profit or not. Like in any other industry, it’s essential to have satisfied customers. But there are other reasons as well, for example operational. Bugs are often corrected first, and usually by the same team that develops the application. Therefore, if we are working on fixing bugs, we are not developing the application, so again we are not doing what can help us make money.
For obvious reasons, the application user also wants the bug to be corrected as soon as possible. So, we have a pretty solid foundation for this. Then why is it that sometimes it takes way more time than everyone would like for a mistake to be corrected? There are at least a couple of reasons, but today I would like to highlight one that seems to be the most common and severe. It is about two-way communication between the reporter and the user, and more specifically about its quality.
Be precise
The key aspect of the quality is precision. The precision with which the submitter describes the error and how it occurred, and the precision with which the reporting operator instructs the reporter. That the precision of transferring information is a difficult matter, even in everyday conversation, everyone who was sent shopping knows with detailed instructions: Buy 6 eggs, and if there are sausages, buy 10. Then you go shopping, check – there are sausages, so you put 10 eggs in your basket …
The difficulty level additionally increases when we communicate in writing, which is most often the case with handling requests. Most often, we report an error by sending an e-mail or filling out a form in various helpdesks. In this case, there are additional difficulties, for example punctuation. As a confirmation that even a single comma can turn the meaning of the sentence upside down, let’s use a story that may already be known to some about a teacher who wanted to send a message to his students in an IT class: We’re going to learn to cut, copy and paste, kids. Yet, his finger slipped and instead he wrote: We’re going to learn to cut, copy and paste kids.
So, obviously the accuracy of what we say and write is fundamental to effective communication. Therefore, we should always try to formulate our thoughts very precisely and, above all, unambiguously. It is good practice to read your report and consider that if I were another person who doesn’t know what I know, I would understand everything the same. Of course, this kind of internal swapping isn’t easy, but with a little practice it can be mastered. This is obviously not the only way we can facilitate communication, but it seems to be the basis for further action.
Important note: precision of speech is an essential element of effective communication not only on the part of the applicant, but also of the operator. Such a person, as a specialist in his/her field and often a technical person, must remember that on the other side of the application there is often someone who does not have the same knowledge as he/she does, understands certain things differently and perhaps does not have a 100% knowledge of the system. Hence, he/she needs clear guidelines. The method of swapping places or simply empathizing with the other person also applies here.
Good practices
Since the basis for effective communication is already established, what are other examples of good communication practice in the helpdesk?
Helpdesk only
If a helpdesk platform is available, always use it to report incidents, not via email or telephone. This has several important advantages. Email may not be received in a timely manner. We can send it but not necessarily to the right person. Helpdesk people are always there. This is the fastest way for our report to reach the right person.
In addition, all the necessary information, screenshots and other attachments will be available in one place. If the person responsible for the notification changes on the service side, he/she will have access to all necessary data immediately.
Information about the application is immediately stored in the database. For a software vendor, this is valuable data about the quality of the solutions it provides. It is possible to measure the time of order processing and other factors affecting the level of service.
Personal application
Make submissions in person. Every dead phone call, even with one contact person, to whom we think we have clearly explained what it is about, is a potential place to twist something…
I had the opportunity to talk directly to a user of one of our solutions who told me about the need to develop the application. The idea was that system lists, which currently can only be exported by users with the manager role, could also be exported by users with other roles. The next day, this need was communicated by the helpdesk by another user and was described as follows: “I am asking for the possibility of adding the import to Excel tab in the list of damages entered into the system”. It was only by speaking to another user beforehand that it was possible to understand what the report was about.
So, report it in person, and if we don’t have helpdesk access, write a ticket and ask for it to be reported exactly as we described it.
More information
The helpdesk reports a notification saying “VSoft is not working”. I look around. People sit at desks and work. The company is still listed in the National Court Register. The coffee machine is working. No – I think to myself – that’s not it. VSoft is currently working. After asking a series of questions, it turned out that the user was having trouble resetting his app password. Thus, the bug which could be resolved in 5 minutes stretched to several hours. Only because basic information was missing.
Correcting and searching for the cause of a mistake can be compared to a police investigation: anything can matter. Therefore, do not be afraid that you will provide us with some unnecessary information. You never know what might be helpful. I personally know a case where the font used by the user was the key to solving the problem.
First of all, describe step by step what you clicked, what fields we filled in, what operations you performed before the error occurred. Provide information on what software version you operate on, what browser you use (if we use a browser solution), what operating system you have, whether the error repeats itself or occurred only once, when it happened, which users it affects, etc. It’s really very important!
New clues
Inform others about new circumstances. Using the investigation metaphor, the police always hand out a business card to you to call them when you remember something. It’s the same here. If you remember something or any additional information appears in the course of further work, you notice something, let us know immediately. The investigation boils down to putting forward hypotheses and looking for ways to confirm or refute them. It should not be done chaotically, a plan should be prepared – a set of hypotheses, a set of experiments that allow us to confirm or refute them, a set of data, information necessary to conduct experiments. Each new piece of data or information can help to exclude or confirm something faster.
Visualizations
Use drawings, screenshots, and recordings. It is true that a picture can say more than a thousand words. Instead of describing the situation with multiple sentences, you can attach a screenshot with some comments.
We can use the tool built into Windows 10 for this. Just click Shift + Windows + S and the selected screenshot will be copied to the clipboard. A great tool is also the free Greenshot, which allows you to take precise screenshots and introduce simple graphic modifications to them right away. We can add something, draw an arrow, mark a fragment – a great thing.
And it’s even better if we can record a video where we show the entire path we took before the error occurred. Windows 10 will also help us here. Windows + Alt + R and voila! We can record the screen.
Business analysis
Perform an internal business analysis. The point is, before you report a matter, to analyse it and, for example, at the beginning check whether the error repeats itself or it was a one-off event. It is also worth consulting with the application’s users. Perhaps someone had a similar situation and knows how to deal with it, knows the workaround. Maybe with the analysis it will turn out that what we wanted to report is not a bug at all. It happens that other users know the system better than we do and can help us. There are many options to consider. Remember that an unfounded report must also be taken by the service and it also takes time, which could be used to resolve the actual error.
Your own IT Department
Engage your own IT department (if you have one). In many cases, the problem lies in the hardware, configuration, infrastructure, and additional software (e.g. browsers). You can resolve a significant number of incidents on your own. So, it’s a good idea to report the incident internally first and if that fails, refer it to the software vendor. The idea is even more appealing as the internal IT department, knowing what is going on, will be able to provide additional information or provide data that will help solve the case.
Checklist
Create a checklist of the notification’s content together with the supplier. A structured report can be handled quickly and efficiently. Then, you are clear about what you receive and what to expect in the report. Before sending the report, you can easily check whether all the required elements of the application form are completed. It is very useful when you rarely report incidents, and you don’t have the habit of including all the necessary elements at once.
A temporary solution does not bite
The most important thing is business continuity and getting back to work as soon as possible. It is not uncommon for users to find workarounds by themselves. The ticket handler will often suggest actions that will temporarily allow you to perform the problematic operation. Sometimes these activities can, for example, allow you to perform a given activity but will take longer. However, it will be possible. Remember that this is not a target solution and such a state will not last forever. At the time when the temporary solution is used, work is underway to implement the final solution.
Emotions aside
Everyone knows perfectly well that there is nothing worse when you are in a hurry with work, deadlines are chasing you, your boss is breathing down your neck, you want to go home, the dog is barking, the milk is boiling, the children are crying (delete as appropriate, depending on whether or not you work remotely), and here suddenly… Error 500. The system has performed an illegal operation. Consult the administrator. And here we are nervously logging on to the helpdesk and trying to DESCRIBE THE ERROR!!!!!!!!!! BIG LETTERS!!!!!!!!! AND LOTS OF EXCLAMATION MARKS!!!!!!!!!!! and we’re interrupting our message with invectives and even more exclamation marks!!!!!!!!!!!!!!!!!
Of course, it cannot be denied that this may have a cleansing and even therapeutic effect, but it takes us even further from achieving the goal which is to have the bug solved as quickly as possible. It is difficult to find the merits in a written application form and focus on important issues. Therefore, always before editing the incident description, take a deep breath and focus on the analysis of the problem and the substantive content of the report, and finally read the whole thing and think if it is understandable.
You can always give vent to your feelings in a separate application form.
At the end
As you can see, the seemingly trivial process is not that simple and can be improved in many ways. However, I think that it is worth taking up this challenge, because it can significantly affect the effectiveness of the request processing in the systems on which we work. Most importantly, all of the above remarks can be successfully applied not only by the users who report incidents, but also by the persons handling them from the software vendor. Solving a bug is a common cause, so effective cooperation is essential in this regard.
To facilitate the implementation of the solutions described here, we include an infographic that can be copied, printed and hung over the desk, and also shared with friends. It will surely be of help in effective reporting of incidents.
And I wish every user of computer system that they will not lead him to know this list by heart.
