Let’s face it. We’ve all been there. Attending a service review with a customer only to be faced with an incident or request that should have been sorted out months (if not years) ago. Such “aged tickets” happen for a variety of reasons – complex systems, organizational change, or even plain old “not enough people on the IT service desk.”
The reality is that these aged tickets hurt us. From the business’ perspective, they have people struggling for much longer than is acceptable and from an IT perspective it means that we “can’t see the forest for the trees.” To help, here are my first five of ten ways to overcome your aged ticket problem.
Tip #1: Get a handle on the number of aged tickets
First and foremost, let’s get a handle on the scale of the issue. Just how many aged tickets are we talking about? Is it in the tens, hundreds, or (if you’re really unfortunate) the thousands?
Make your IT service management (ITSM) tool work for you by running reports on aged tickets. When we’re tackling old tickets, we like to break down reports by:
- Tickets over 10 days old
- Tickets over 30 days old
- Tickets over 60 days old
- Tickets over 90 days old
- Tickets over 120 days old.
This will give you a starting point.
In an ideal world, your ITSM tool should be able to give you a view or report on aged tickets. If you don’t live in that ideal world, then use spreadsheets and formulas to understand and group tickets into aged bands such that you can get an idea of your biggest pain points.
For example:
- Lots of issues that have breached the service level agreement (SLA) but are only just over 10 days old? This could be indicative of processes being dropped or too many reassignments.
- Lots of tickets over 120 days? Is a key person on long term sick leave? Has here been a restructure? Are there support teams in your organization that need a refresher course on queue management?
Tip #2: Get a handle on the ticket type
Another way to prioritize your workload is to split out your aged tickets between incident or service requests. Incidents are break-fix – essentially something’s broken or we have a user unable to work. Service requests, on the other hand, are something that’s more along the lines of “Please can I have?” rather than “Something’s broken.”
Tip #3: Understand the impact
Look for your biggest hitters and sort by priority. If you have any priority 1 or 2 incidents that are over ten days old, focus on them first. If an incident is a priority 1 or 2 typically this means the potential for a major incident – so, make sure they’ve been prioritized correctly and aim to fix them as soon as possible.
Another possibility is that the incident was raised by a VIP in your organization. Again, speed is of the essence. If your CEO can’t access their email during a contract negotiation meeting that’s not a situation that will end well for anyone.
Tip #4: Look for quick wins
Have a quick scan through your aged-ticket queue. Is there anything that has already been fixed but the ticket hasn’t been closed? Maybe there’s a training issue where service desk analysts aren’t closing tickets and leaving them at the “resolved” state. Or maybe the end user never got around to confirming that all was well, and we forgot to follow up. Or maybe the original ticket refers to a service that has been retired and is not in use anymore.
Plus, are there any service requests that can be resolved by one quick check against the software license database or by having someone on the team set aside a couple of hours to blitz through an access request backlog?
Look at what can be resolved quickly such that you then have time to focus on the more complicated issues.
Tip #5: Start with the oldest first
Now that you know there are no potential major incidents in your aged-ticket queue, go through your tickets in date order so you can keep track. The first thing to do is establish that the ticket is still genuinely causing pain.
If the incident is years old, it can be embarrassing to contact the end user asking if their email client keeps crashing – so consider your approach. One option would be to contact the end user saying that as part of an improvement initiative, the IT department has found some aged tickets, weren’t sure of the status, and wanted to check if the issue was still ongoing and, if so, to agree on a fix plan.
It’s not perfect we know, but it sounds a lot more professional than, “Sorry, we forgot all about you.”
So, that’s our first five tips for reducing aged tickets. Visit the second part for more ideas to reduce ageing tickets.
