Ticketing systems are everywhere, airlines, apartments, work. Everyone's reached out to one (sometimes not knowing it's a ticketing system!) at some time before, but despite the ubiquity of them many of us aren't the best at putting in good tickets.
Good tickets contain enough info for the person at the other end to understand what the problem is and determine a course of action. These tickets tend to include things like screenshots, error codes and descriptions of what was going on at the time. They not only provide the WHAT, but also the HOW and the WHY behind the ticket.
The bad
Before we look at what makes a good ticket, we need to understand what makes a less than good ticket. Consider the following (let's also assume the ticketing system knows who you are, what time it is, etc):
“Help! I can’t log into system ABC.”
This does tell us some information, that you cannot log into ABC, but the information provided is very limited. If I'm a very good tech I would first check to see if you have access to ABC, or if you're even supposed to be able to (its surprising how many times people try to log into systems they shouldn’t!). More likely, a tech will look at this, roll their eyes, and respond with something like:
“Ok, tell me what happens when you try to log in.”
While this response is typical, it doesn’t do much to get more information from the customer, and it doesn’t help establish positive rapport (not the scope of this discussion, but also very important!). Ideally the tech should do something more like :
“I understand you’re having trouble with ABC. I see you do have an active account in ABC. Could you please got to this link, try to log in with you username and password and send me a screenshot of your entire screen with what happens?”
I won't get too deep into how to properly answer tickets (a fascinating topic worthy of it's own discussion!), but this approach provides clear next steps for the customer. It also clarifies some assumptions, such as the user knowing where or how to log in, or them forgetting their credentials.
A Good Ticket
Short of just getting “Help!” (which does happen!) the example above is basically a worst case. A good ticket is one step up by providing more specifics, such as an error or screenshots. Thankfully more often than not customers fall into this bucket, mostly due to previous experience and/or training. It looks something like:
“When I try to log into ABC I get a ‘account not found’ error, help.”
This clearly states the problem, and provides some technical info to look into. It's better than the bad example since we get that error message, but even here more info would be really useful. For example a link to where they logged in, or telling us it worked yesterday.
Really Good Ticket
Rarely, oh so rarely, I see an exemplar. A ticket worthy of being printed off, framed, and hung on the wall as a shining beacon to direct people to. Something like :
“I tried logging into ABC at this link, but got a ‘account not found’ error (see attached). I could log in with my username last week, and don’t think anything’s changed. I need to get in to pay everyone. Help.”
This one gives us everything:
What - they can't get in, and am error plus screenshot
How - at a specific website, with info on it working before
Why - a business reason which helps determine priority
This information removes a lot of the guesswork for the tech. They should still double check, but now they know what to look for, and when to look (sometime in the past week). It’s also possible this info will trigger an immediate answer (e.g. system maintenance is ongoing and locking folks out), or otherwise clue-in the technician to something that may be impacting them.
While I concede our users won't do this all the time, we need to set the expectation on them to give us good tickets. Folks should be regularly reminded how to put in tickets, and that putting them in properly is beneficial for everyone. Not only does it make our techs lives easier, it decreases back and forth, shortens response time and makes everyone happier.