I feel that people who resolve and close help desk tickets have a duty to close them in such a way that the information they give is useful and allows fault-and-trend analysis. If a fault occurs, it is an opportunity for us to learn about the systems in our care.
Whenever you receive a help desk ticket you have to remember that it is about more than the loss of service to the end user. It isn’t just that their equipment isn’t working, but also the fact that the lack of working systems is preventing that person from doing what they need to do. Our first priority is to get the client working again; we worry about the paperwork afterward.
When the department head looks back over the month’s activities, they aren’t doing it for entertainment or to make themselves look busy. They are looking for patterns, such as reports on a particular piece of equipment or a particular comms link. They are looking for indications that there might be a requirement for upgrades or additional user training.
The only way that we can learn from our faults is to record them. The only time when it is permissible to close a ticket with a single word in the freeform text field is when a single simple action is performed, such as resetting a password. Entering “Reset” or “Done” is suitable in such instances.
When the problem is any greater than this, it is vital that all corrective actions are recorded, so that the next person to encounter the problem or try to research it has a little more information to work with.
We aren’t looking for War and Peace, but if there is a solution to the problem and it hasn’t been recorded before, it is essential that you record the steps taken. If the solution is too long-winded to record in a help desk ticket, then record it in the knowledge base and reference the KB article in the help desk ticket.
Some help desks don’t record password resets, but I think that is a bad idea. Some people have problems with passwords and may have a need for some remedial training. Being able to review a person’s call history and discover the reasons for the problems can provide very useful information.
An example of this was a lady named Danielle. It seemed that she was having real problems with her network login. No matter how many times we reset it for her, she came back to us on an almost daily basis with login problems. Being short on time, we would reset it and move on, but her plight was noticed during the end-of-month review.
A closer look at her account details revealed that her login had been set up with one-day password duration, a silly mistake from our team and not, as we thought, evidence of her air-headed behavior. The reason why we didn’t notice this immediately was that we didn’t take the time to ask the right questions. We just assumed that she was getting it wrong. Had we listened to her we would have learned that she wasn’t getting an incorrect password message but a password-expired message.