If you work in a support capacity, one of the most important things you can do is track your work. The common way of doing this these days is with ticket tracking systems. Recently at my day job, we implemented what can only be described as the worst ticketing system any of us have ever used*, replacing one of the best ones.


Companies have to look at a lot of factors before deciding on a ticketing system. I admit that cost is one, and I don’t know the cost differential between our old one and our new one, or between any of the ones I might mention here, but I do know that, as a user of ticketing systems, there are certain things that simply must be present. Here are six of them that you need to consider — or that you need to make your boss consider.

6. Fast — First and foremost, your ticketing system has to be fast. Fast to use, fast to file tickets, fast to respond to them. Your customers’ problems are the #1 most important problems anyone has ever had in the history of the known universe — at least to them — and you need to be able to address them quickly. Or, failing that, you need to at least let them know that you’ve received the ticket and are going to work on the problem soon.

Fail… Our new system at work is not fast. The only fast way to file a ticket is to use the web form that our developers built, which feeds the data into a ticket and auto-creates it. Trying to create a ticket by hand is a very slow process, and our customers couldn’t even begin to figure out how to do that.


5. Portable — Next, your ticketing system needs to work on everyone’s computer, in every browser, and (if at all possible) on mobile platforms as well. Who knows what each person’s browser of choice is going to be? You can’t limit people to IE, or Firefox, or Chrome, or Safari — especially if interoperability and portability is a requirement. It also has to be easy to log into — URL, username, password, and the URL needs to be simple.

Fail… When they rolled out our new system at work, we didn’t even have a way to view our tickets; the links in our e-mails didn’t work. I had to file a support request to get the information, and then I handed it to anyone who asked. Training was only about how to submit tickets, not about how to manage them.

4. Customizable — Every team has different things that they support, and support can fall under all sorts of things. Support isn’t just IT or network operations; support is “our website is broken” or “I need you to build some marketing graphics”. To that end, your ticketing system has to have fields that can be added, removed, renamed, changed, hidden, and shown.

Fail… Nope. This system has one set of fields and that’s it. The one I used to use at my past three jobs, JIRA, is unbelievably customizable. I used it for advertising issues, creative tasks, technical support, and web development. The new one is to JIRA what a medieval peasant is to Stephen Hawking.


3. Communicative — When I update a ticket, I expect that the ticket reporter is going to be notified. When the ticket reporter updates the ticket, I expect to be notified. Otherwise our service level standards suffer — and, worse, our clients suffer because they think we’re not replying to them when really we’re just waiting for them to give us more information.

Fail… Which happened to me for about three weeks. In the new system at work, the only ways to notify someone of a ticket are:

  • Assign it to them.
  • Resolve or close it.
  • Use the built-in e-mail functionality — which is in a separate part of the system, hidden behind a menu — to generate an e-mail. Now, thankfully, this e-mail becomes part of the ticket record, but I still shouldn’t have to take this extra step.

2. Collaborative — I can handle a lot of issues on my own. Got a problem with our reporting software? I can take care of that. Something acting up on the site? I can usually do something about that. But my job — and the jobs of many others — is highly technical, and often that requires bringing in other members of my team. A ticketing system should support this collaborative spirit. But beyond that, it should also allow other people to observe a ticket, and should I fall ill and be unable to work, it should allow other people to assign my tickets to themselves and work on them in my absence.

Fail… Our new ticketing system only allows people specifically assigned to a team to view a ticket for that team — so, if I’m on Team A, then only people on Team A (and superusers) can view our tickets. However, if I assign Ticket 1 to myself, then no one but me and the ticket reporter can see the ticket. No matter how hard they try. The day I wrote this column, I had to bring a developer in on an issue and he couldn’t load the ticket because he’s on Team S; if I had assigned the ticket to Team S, then I wouldn’t have been able to see it. And at my old job, we often set product and project managers as watchers on tickets, so they could keep track of work being done; with this new system, there is no concept of “watcher”.


1. Universal — If you’re going to roll out a new ticketing system, you need to have something that you can roll out to everyone at the same time. I understand the concept of doing it in small parts, but when you have a roll-out this big, you need to just rip the band-aid off and get people using the system immediately. And everyone has to use it, which means it has to work quickly, portably, and collaboratively; it has to be customizable, and it has to send notifications to all stakeholders. This is why the people who work with the system, both as customers and as supporters, need to be included in these decisions.

Fail… This is the biggie. See, if you’re going to have a ticketing system, you need everyone to use it. You can’t have:

  • Teams that refuse to use the system because they just don’t want to. We have a team that simply won’t switch over to the new system. Recently I had a ticket come in that required me to work with that team; I had to walk over and explain everything, and I have to update the ticket every time work is done on it, because that team uses a proprietary ticketing system that no one else in the company uses.
  • Teams that are required to use alternate systems because the company realizes that the new system isn’t workable for them. This applies to the guy on Team S that I referenced earlier; he has access to the new system, but his team primarily uses a different one and that’s not going to change. Ever.

Bonus Content!

If you’re going to move everyone to a new ticketing system, then you need to do two things well: you need to train them all, and you need to give everyone access.

I recently was part of a roll-out of some new software to the team I support. They were trained by the vendor, and I am continuing to help with training as needed. I’m also in charge of all user accounts, which comes down to people saying “give John Smith access to Record Set F”, and I give John Smith a username, a password, and access to the record set he needs.

Compare that to the roll-out of this new ticketing system. I’m still helping people navigate it because no one else will, and some of our users don’t even have accounts — one of our people has spent over a week working with the team that supports the ticketing system, trying to get herself an account so she can file tickets… but if she can’t file a ticket to get an account, then how can she get an account to file tickets?



Got an idea for a future “Six of the Best” column? Tweet it to me @listener42.

* This is how bad it is: I recently was talking to a friend of a friend and it came out that I’d just gotten hired at the same place he works — the company has over 20,000 employees worldwide, and though we work in the same town, we’re not in the same building. We immediately began bonding over how awful the ticketing system is.