Ten things to look for in your ticketing software.
It’s all very well to hire the most experienced ServiceDesk technicians you can lay your hands on, but if you’re giving them substandard tools, they can’t give you their top results. It’s true of office furniture, it’s true of computer hardware, and it’s true of the #1 tool they’ll be using every day – the ticketing application. Here’s what to look for.
1) Two-way hooks. If your ticketing application can pull data from elsewhere on your system, and automatically write back out to your in-house choices of database, archive, and report software, that’s a huge amount of work that you don’t have to pay actual people to do. Too many technicians spend 90% of their time cutting and pasting, when it should be automatic.
2) Speed tweaks. Does your software allow you to change the default screenflow to suit the way your people do things? Does it keep track of how long it takes to perform certain tasks (including screenloads), and how long on average it takes for a technician to get from A to B in the interface? Does it allow itself to be adjusted to minimise these delays? Can it preload data? If not, you’re pretty much paying your entire team to sit around for three to four hours a day, waiting for your software to stop twiddling its digital thumbs.
3) Redundancy. Does your ticketing software use a back-end server to co-ordinate ticket numbers and store a centralised archive? And if a technician’s PC loses its connection to that server, or if the server goes down, is the ticketing application smart enough to seamlessly switch over to non-networked mode, then resynchronise with the back end later on – without slowing down anything else on the PC?
4) Automation. What workflows does your software handle automatically? What data sources of yours does it check in the background as the technician is working, so they don’t have to waste time doing it manually?
5) Template balance. Are you using no templates? Templates for everything? Both are usually bad ideas. Templates can speed up input for common issues, but there’s just no way they can cover everything, and if a technician has to remember and search through more than a dozen or so basic forms, they’re wasting time.
6) Nonlinear input. If your application absolutely requires that ticket information fields be completed in a certain order, it’s already holding your people back. There is no excuse for hardcoding this at all. A default order is fine, but (as above), it must be able to be changed, and must be overrideable at all times. Your technicians are smarter than your software – don’t make the sides fight, especially when you’re paying.
7) Autoguessing. The longer a ticket application is in use, the more information flows through it about what options technicians are likely to select next. Is your application using this information to preselect and preload likely data, including text templates, button and screen workflows, and the output of other applications and utilities? Is it personalising those preloads to enhance the skillset of individual technicians? Does it allow its autoguessing rules to be manually edited?
8) Soft-required fields. There’s almost never an absolute requirement for a field. Don’t prevent your technicians from completing 98% of a ticket because the one data item you marked as mandatory isn’t available. Flag it if you want, make it flash red or orange, log it to a file to be assessed later by a supervisor or senior tech, but don’t force your people to spend their valuable time finding ways around your brick wall.
9) Object attachability. There’s nothing quite as annoying as a text-only ticketing system. At the very least, technicians should be able to paste in screenshots. Put RTF or HTML compatibility (for instance) in your main ticket body, and they’ll be able to attach/link files and objects to show auditors and trainees exactly how something went wrong, what to look for, and how to fix it. The only thing worse than spending half an hour transcribing a set of immensely long error messages is paying your top technicians to be a typing pool.
10) Customisable interface. A good ticket application will be able to adapt to any business. But by the same token, it will have a lot of features and extras that you may not need right this second. Check to make sure that your service desk is able to tweak the presentation and flow of their most heavily used interface to tune it precisely for your requirements, and squeeze an extra ten to fifty percent speed out of it.
So if you’re after efficiency, or just a way to turbocharge the service desk, start with what’s right in front of them.
Copyright 2009 © – This article was written by Steve Davidson on behalf of Help desk association of Australia.