Capturing The Perfect IT Support Ticket

An accurate IT support ticket allows service desk analysts to quickly and correctly fix technology problems. So what information should the “perfect ticket” contain and how do we capture this from customers? 

The perfect IT support ticket underpins faster most-cost effective service and a better customer experience  

The perfect IT support ticket underpins faster most-cost effective service and a better customer experience  

The support ticket sits at the sharp end of the IT support process. Yet despite the importance of recording the right information at the ticket capture stage, it is often overlooked. The majority of ticket capture processes are flawed, failing to capture the detail that analysts and IT support staff need to fix issues in a timely fashion.

What’s missing from our support tickets?
Most support tickets ask for one piece of information, which can be broadly described as ‘What’ i.e. what has happened.  This approach may allow a customer to log a support ticket quickly, but it costs far more time than it saves. When a ticket lacks information, a back and forth scenario plays out, with the analyst asking follow-up questions of the customer. If the ticket contains the relevant details to begin with, this needn’t happen.

The problem is that to fix the majority of IT support issues, the analyst needs more information than the ticket currently gives them. Borrowing the journalistic technique to ensure the full story has been told, support tickets need to think about the complete picture, i.e., Who, What, When, Where, Why & How.

Who is submitting the ticket? What department do they work within? What device(s) or IT services does the ticket relate to?

What has happened? Of course, this is still important: perhaps the key piece of information. But as we are seeing, ‘What’ only tells part of the story.

Understanding the time scale is essential. Tickets often relate to issues that have been fixed since the ticket was logged, and awareness of the time can be the difference between an analyst researching the resolution from scratch, and issuing an immediate response/closing the ticket.

Historically, this relates to where in the building the ticket was reported. While this is still relevant to large organisations, ‘Where’ is especially important now the workforce is mobile. The location that the ticket was reported from has a major bearing on the support that can be offered.   

In the context of IT support, the ‘Why’ is crucial. ‘Why’ is about the conditions that led to the ‘What’. In other words, Why has the problem occurred, what did the user do that led to the problem? This is all too often overlooked when collecting support ticket information.

If the first five steps have been understood correctly, then ‘How’ may be redundant. But if asking “what happened” and “why did it happen” isn’t enough, asking “how did it happen” is sometimes the direct question that is needed to complete the ticket.

Gaining the complete picture of an incident is critical to delivering effective IT support. Check your own processes and reference some sample tickets against the who, what, when, where, why and how criteria to see if you’re falling short. 

Once you’ve understood the information that a perfect IT support ticket should contain, then you need to think about the equally important factor: how the ticket itself is captured.

Why your IT support ticket capture process is failing
One of the reasons why IT support tickets contain such a paucity of useful information is the method used to record them.

For example, think about the incumbent IT support interaction carried out via the phone.  A phone call is very time-consuming, both for the customer and the service provider.  A phone call demands that the customer stops what they are doing, make the call, navigate the automated menus and then explain the entire issue to the analyst.  The analyst must then listen, converse, record the conversation and respond, all in real-time.  

The multi-tasking aspect of the call is why it is an error-prone process - both in terms of capturing the ticket correctly and fixing the customer problem. Using the phone to record a ticket relies heavily on the communication layer. Is the customer able to accurately describe the problem? Is the analyst able to interpret and record the incident correctly? When you think about capturing support tickets in this manner, and the detail that a good support ticket needs, you begin to see why the quality of tickets varies so greatly.

Yet it’s not just the phone call method that is flawed when it comes to capturing ticket information.  Email has the advantage of taking the real-time pressure away from the service desk analyst. But just like a phone call, it is open-ended. It relies on the quality of the email which the customer sends, and the skill of the analyst receiving it, as well as the follow-up questions sent. Just like the phone call, email leads to an ad-hoc way of capturing support tickets, which leads to inconsistent service.

The inherent flaws
Service desks and support teams have tried to circumvent the inherent flaws in capturing ticket information by scripting the process. This leads to clipped, awkward and elongated phone calls which demand the customer answers multiple, often irrelevant questions.  Email forms are is not much better, necessitating the customer fill in endless fields of information to log the problem.

There is another way: the customer service portal. Automated ticket logging, typically facilitated through the company intranet or a public facing website, is a much better way to log tickets. Self-ticketing is less time consuming for customers and is in keeping with the current culture of using online self-help rather than making a phone call or sending an email. Portals also allow the service provider to guide the customer through the support process, asking questions in the context of the previous response.  If managed correctly, a portal is therefore far more efficient and accurate than the phone/email method of capturing IT support tickets.

These reasons are why portals are increasingly being favoured for logging support tickets. However, the portal needs to be effective. Most support portals are generic, lack personalisation, ask inappropriate questions, provide too little detail and have limited contextual awareness.

Building a better support portal
Creating a customer support portal that captures the perfect IT ticket is therefore heavily dependent on two factors. Firstly, the people building the portal and their knowledge. Secondly, the technology powering the portal.

Let’s start with the former.

The people building the portal are responsible for populating the knowledge it imparts, and the questions it asks. If they get it wrong, the portal will fail customers. So how do you establish what information and line of questioning your portal should follow to populate the tickets with the correct information?

- Root Cause Analysis and number crunching
Looking at your incident stats is highly beneficial at this stage. If you know the common problems and outcomes, this can be built into the ticketing stage.  Understanding the basis of common issues and their associated fixes is fundamental. This knowledge will allow your customer support portal to both deliver automated support to the customer, e.g. here’s an immediate fix for the issue you are logging, or collect the data the analyst needs to resolve the issue.

- Speaking to customers…and staff
Beyond analysing issue root cause, what challenges and issues do your customers have that don’t always show up in the stats? Speak to your colleagues and service desk staff. They understand the nuances of the business and the common language that is spoken, so they should be heavily involved in the ticket capture stage.

- Feedback
Improving the IT support ticket process is just the beginning. You need to regularly check its effectiveness and relevance to ensure it is still capturing the right information.

Is the technology good enough?
To improve your ticket capture process, you will have to customise your support portal. Every organisation is different and your ticket capture screens should reflect your information requirements for support. Thankfully, support tech is improving, and many service desk and customer service tools allow you to customise fields.

At Richmond, we’ve taken this a step further. The speed and ease of building a customer support website using Richmond Customer Service Portal mean that not only can you customise screens and fields using drag and drop, you can build an entirely new web portal within minutes rather than hours and create portals for specific departments and customer types.

For example, the support questions answered by external customers are likely to be completely different to the technical problems faced by your internal departments such as IT, facilities and HR. There are two ways to tackle this. Either you build a single huge, sprawling portal, which forces customers to go through many steps to record their issue. Alternatively, you can build portals specific to each customer type. This means that each support department has its own branded portal and the support ticket capture forms and questions are written specifically to capture the information that is right for them.

The power of this level of personalisation is huge. The more accurate and specific the ticketing process becomes, the faster and more effective the service ultimately delivered.

Support ticketing might appear to be a simple process, but there is far more detail involved in doing it well. The difference between a generic, basic-information ticket, and a fully-detailed ticket equates to the difference between a ticket that stays open for days and a frustrated customer, versus a quick resolution and highly satisfied customer. If you apply that formula to each of the many tickets service providers deal with each day, the cumulative impact is huge.

Need help with your ticketing? Want to see how a flexible customer support portal can transform your IT support ticketing? Book a free online workshop now: