Tagging and support analytics
I saved the most exciting topics for December
Today we’re going to talk about another higher-level issue that has specific tactical implications: ticket tagging. This, in case you’re not familiar with it, is the process of adding relevant metadata, or ‘tags’, to individual issues in your ticketing system to assist in future searching and ticket analysis. For example, if you’re looking for tickets related to authentication issues, you might search for ‘authentication’ … but also related words like ‘login’, ‘password’, ‘key’, and who knows how many other terms—and you might still miss some. But if you and your team have been regularly tagging tickets, you could just search for the ‘authentication’ tag and be reasonably confident that your search results contained all of the relevant authentication-related tickets in your system.
I recommend checking out my earlier post on ticket categorization and specifically the last section, Some notes on categorization, but in case you’re in a hurry, here are the main takeaways of that section:
Your categories are going to be specific to your own support team and the profile of issues you receive
Your categories need to be granular enough to be useful, but not so granular that trends get lost in the noise
Don’t forget the ‘other’ category for anything that doesn’t fit anywhere else
Categories aren’t set in stone: review them regularly to make sure you’re getting useful data
OK! With that behind us, let’s move on to today’s topic: effectively tagging tickets, and what you can do with that information.
Everything you ever wanted to know about tagging but were afraid to ask
On a surface level, issue tagging is very straightforward. At some point during the ticket cycle, the ticket owner adds a few tags that are relevant to the content of the ticket. Going back to our authentication example above, you might add ‘authentication’, ‘bug’ (if it is), and ‘windows’ to reflect the platform the user was on. You probably already know where I’m going with this: it gets pretty complicated pretty quickly when you actually try to put tagging into practice. So based on my experiences in implementing a tagging regime for support issues, here are some best practices that may help avoid some of the pitfalls you may encounter in your process.
Mandate tag application
Tagging is only useful if it’s applied consistently. If only 50% of tickets have meaningful tags, then you’re worse off than before. You may think you’re finding all of the authentication-related issues by using that tag to search, but in fact only about half of them are tagged. So you need to figure out a way to make sure everything gets tagged. Some issue tracking systems can require tags, which is a start, but the best way to ensure this gets done is through education. Emphasize the importance of tags in your onboarding process, make sure that established support engineers model proper use of tags, and spot check random support issues to verify that they’re being tagged.
Control the vocabulary
Many systems that allow tagging permit free-form tags: you can write anything you like as a tag, and if the tag doesn’t exist, it will be created. This is all well and good, and very flexible, until you realize you have six different tags that all mean exactly the same thing: ‘login’, ‘logon’, ‘Login’, ‘logging in’, ‘sign in’, ‘signin’. Now you’re back to your original problem, where you need to know a bunch of different terms to search for when you’re looking for tickets related to logging in. There are a few different ways of managing this, depending on the capabilities of your system.
Disable automatic tag creation: if a tag doesn’t already exist, an admin has to create it. This keeps tags under control, certainly, but can slow things down quite a bit if you have to wait for your supervisor to add a new tag. It certainly doesn’t encourage consistent tagging.
Periodically review and merge tags: some ticketing systems do not permit this, but for those that do, it’s worthwhile regularly checking through the list of valid tags and merging ones that mean the same thing. Those six login-related tags can be merged into one, and things will be a lot cleaner. The downside to this is that it’s a never-ending task: you’ll need to keep on top of it to keep your tags from endlessly proliferating.
Make it easy to use preferred tags: for the most common tags, make them front and center for selection in the ticket management interface. For instance, for tagging the main ticket topic, you might pre-populate a dropdown with the ten or twelve most common categories. While user-submitted tags are available, they needn’t be used unless none of the existing categories are appropriate.
Don’t overdo it
Like so many other aspects of ticket handling, proper tagging is a balancing act. On one hand, you want to add enough tags to be useful for future analytics. On the other, you want to avoid spending so much time applying appropriate tags that you neglect actually working on the customer’s issue. In most cases, two or three tags is a happy medium: enough information to aid ticket analysis, but requires no more than a couple of minutes to take care of before diving into the ticket troubleshooting process. On a related note, remember that your initial impressions may not be accurate. Be prepared to update the tagging later on in the ticket lifecycle if you realize that your initial categorizations were incomplete or incorrect.
Train your team
By giving your team multiple examples of correct tag use, you can make sure everyone is aligned on the meanings of the various available tags. Ideally, once this training is complete, you could give each member of your team the same ticket to tag and they’d all use the same tickets in accordance with your team’s standards. Now, back here in the real world, that level of consistency is probably never going to happen, particularly when you have hundreds of available tags. But periodic training and updating of available tags will greatly increase tagging consistency across the support organization.
That said, it’s important to pay attention to those exceptions where tags are being misused or going unused entirely. If your team is constantly misusing one particular tag, that’s a good sign that it may be too vague. Review it and maybe replace it with something more precise. Same for tags that are never being applied to issues: perhaps they’re too specific and hence not useful for your team.
Analytics
Why do we spend all of our time considering and tagging? So we can search for related tickets, for sure, but also so we can do useful ticket analysis. Without any tagging, all you can analyze is the ticket metadata:
Date/time received
Time between request and response
Total resolution time
Requester / requester’s organization
Ticket urgency
… Things like that. Now, all of that is incredibly useful to know! Having a graph of busy hours vs quieter times can be critical in justifying your specific staffing model. Noticing that 80% of your issues are coming from 20% of your customers can indicate that you need to look more closely at those customers and how they’re using your product. A predominance of high (or low) severity issues can point to problems with the product itself, or a lack of documentation, respectively. But all of your analysis is missing a critical dimension if you don’t know the actual content of those issues.
Now, let’s consider what you can accomplish with effective tags. The most obvious is effective ticket categorization (see the link up at the top of this post for more on that) but there are a lot of other things you can glean. Just as a few examples:
Issues related to your product’s infrastructure only seem to be coming from enterprise, not SMB (small/medium business) customers
Over 10% of your tickets are questions about a specific aspect of your product’s functionality
Over two-thirds of the bugs your customers are finding in your software are in the Windows version
The rate of negative CSAT related to product Y has tripled in the last two months
The more you know about the contents of the support issues your team is fielding, the more you can tailor your support processes, and the more information you can bring back to other teams. Beyond this, there’s one more really important thing you can do with strong support analytics, which we’ll discuss next week: telling a compelling story once budgeting season rolls around.
Next time … justify your love existence!
Thanks for reading Andy's Support Notes 💻💥📝!