Longer answers are better support

When working tech support, it is often tempting to give short answers to a ticket, in order to get on to the next ticket. This tendency is particularly problematic when responding in the negative to a request. Though understandable, we should fight this tendency. I have three specific reasons why it’s important, but I would also like to note that this is closely linked to Continual Service Improvement in ITIL, or the Improvement kata in DevOps.

1: Better customer service

First and foremost, giving a longer, more detailed, answer is better customer service than giving a short, curt one. While I’m not saying you should write a ten-page essay for each request, giving an answer which not only reports the status of a ticket, but also offering the reason for that status is going to improve the level of customer service, which in turn improves levels of customer satisfaction.

An example; your end user requests installation of a piece of software which is banned by the organisation. While a simple “No, we will not install the software” might suffice, the user would likely become annoyed at the answer, and take that annoyance out on the support tech. Instead, try this on for size: “We regret to inform you that we can not help you with this software, as it is prohibited for use due to organisational policy. Contact PERSON RESPOSIBLE FOR SAID POLICY should you have any questions about this policy.”

Not only is the customer given a reason why the request is denied, they are also told who is responsible for that reason, and encouraged to contact said person.

2: Reduced touch time per ticket

Perhaps somewhat paradoxically, giving longer answers will, in the long run, reduce touch time (i,e, the time spent working on a given ticket) per ticket. It reduces the number of emails back and forth between the customer and IT support, as well as the number of times a ticket is re-opened. This is one of the reasons why tier one support often have a script they need to follow; by asking the questions in the script, and making a note of the answers, they have the information needed to resolve the request.

Having solid information to work on, and providing enough information that the customer has an understanding not only of what has happened, but why it has happened is inevitably going to reduce rework.

3: Documentation

The third reason is that a ticket which is answered with a little more text also demonstrates better documentation. This is important for many reasons. Not only is it a relatively easy way to cover your behind (without appearing to do so), it also means that colleagues can more easily evaluate the ticket, should they read it weeks, months, or even years down the line.

While having documentation is particularly useful when dealing with the inevitable troublesome user, it’s useful even when dealing with more reasonable users as it provides insight into what requests have been dealt with in the past.