When I describe our software to people not in our industry, one of the points I always make is that when deployed properly, our software captures intellectual property that might normally be lost when an employee leaves the company. The key to capturing that IP is properly recording and categorizing help desk tickets. Categorization is the key to finding problems that have been reported before and using that information to solve the problem faster and at less cost each time. Proper categorization is also the key to customers finding information in your knowledge base and solving the problem themselves.
Today we have many search tools but customers still need solid categorization. Our experts have some advice on what makes for a good category structure and how to manage it over the years. I think this is not only solid advice for iSupport but for any software tool that requires you to create and maintain some form of categorization.
Ryan Terrell, VP of Sales and President of the Daren Nelson Fan Club
For me the topic of categories usually comes up in the context of replacing an old installation of help desk software. In 15 years I can only count a time or two that I can remember someone wanting to retain the category structure they had in place. The vast majority of my clients wanted to take the opportunity to start over. When I’ve asked why I’m usually told that the old categories were put in place by a predecessor and over time they had just turned into a mess. In almost every case I find that the organization never put any process in place to manage the categories. They tried to think of everything they would be supporting at the start of the project, and just added and added without much of a methodology.
More often than not, in an IT help desk scenario your categories are always going to be changing. As cool as they were at the time, you probably don’t support too many Handspring Visor Deluxe PDAs these days. So if you ran across that lingering category would you just remove it? What about all the things that may have been associated with that topic like FAQs, self-service articles, support rep skill sets, or templates? Even being aware of that bigger picture without a plan to consistently review your categories, with time and turnover you’ll likely end up with the mess people so often cite. Looking forward you also know that there is likely going to be things in your support future that you don’t anticipate today. Think of the bring-your-own-device trend that is happening more and more. When it comes to mobile computing, you’re likely to hear of a new device every week. That said, I wouldn’t suggest trying to think of them all up front. Put a process together that reviews your tickets regularly so you can add and remove things that make the most sense, keeping in mind that it’s OK to have some lower level categories marked as “Other”. In fact, those bail-out categories can be very useful if you manage them correctly.
Every organization will be different. Using the bring-your-own-device scenario above, think of having a top level category of “Mobile Device”. Maybe below that you have a choice between “Tablet” and “Phone”. At this point you might know everyone in the company was given the choice of using either an iPad or Nexus tablet. Other than the different generations, you probably don’t need to name any more on that branch. But when it comes to phones, you know it’s all over the board. There at the next level from “Phone”, it would be smart to have the most common devices alone with an “Other” category. From there as you review tickets you can start to see trends where it might make sense to add the more commonly-reported phones, which can then spur knowledge articles and templates to automate solutions for the most commonly documented issues. The downstream effects of a regular review will open up a lot of places where you can realize even more efficiency down the road.
As I write this I’m thinking of how simple it sounds yet how often I hear about the results of organizations neglecting to do so. I’ll always suggest that clients regularly meet and review the categories that are being used or are no longer needed. Making the adjustments regularly, you can avoid the ever-growing pick lists that become unmanageable when people just pick something and move on. You’ll create the opportunity to get much better data entered into your system, and it won’t be such a monumental task to create the appropriate knowledge articles, FAQs, or templates. The help desk is an ever-changing piece of a growing organization that needs to learn, improve, and adapt. Put processes in place to manage your categories regularly, and you’ll be well on your way to doing just that.
Lisa Kienle, Pre-Sales Engineering and Cat Whisperer
Categories are such an important component in iSupport. It’s the one area that I’ve done the most consulting on over the last 17 years. They are involved in reporting, knowledge entries, custom fields, unique business rules, and routing…and those are the areas just off the top of my head.
The biggest challenge I’ve tried to resolve is whether you categorize the issue as what is being described by the customer, or as the actual issue. If a customer calls and says they can’t print, is it categorized as Hardware | Printer? After digging in you realize that it’s because the app didn’t have the printer configured, so should it be recategorized as Software | Printer Setup?
If you categorize it as it’s described by the customer, searching the knowledge base based on similar key words would find the solution, even though it doesn’t really have anything to do with hardware. But if you wanted to know how many calls you got last month on printers not being correctly configured in applications, you wouldn’t report on the Hardware | Printer category.
So what do you do? How would you create a category structure that gives you the most functionality? There is no right answer – you have to create a structure that will meet the majority of your needs. In my example, if your user community is active in researching their own issues before contacting the service desk, it will be better to categorize incidents based on how the issue is described. If you need to produce mega reports, KPIs, and stats and justify hardware replacements, staff increases, etc., tailor your categories more toward the actual issue.
This is a difficult decision for customers to make – both aspects are important and both have great value. The happy medium comes in building a structure that doesn’t present multiple options for the same issue. If the user says they can’t print to their main printer and the issue turns out to be a print driver, rather than having a category for Software | Printer Setup you should limit that type of category to Hardware | Printer Setup…even though it’s done through an application. Your reports can then tally all issues with Printer Setup, regardless of the application the user is trying to print from, and the end user can search on “printer” to find possible solutions.
Once you feel you have your categories built, have your techs try to categorize a day’s worth of incidents with the structure. If they struggle to find the right category, revisit the structure WITH THEIR INPUT. Is it that they are just not familiar with the terminology, or do you have too many ways to categorize the same type of issue? Could they categorize it under a Software heading and a Hardware heading? If so, look at a way to combine the categories and then be sure to educate your techs on how you have designed the structure.
Lisa Kimery, Documentation Queen Who Really Wonders How Many Times She Has To Tell Me It’s It’s and Not Its
Consider the types of functionality that you will implement in iSupport, and the scenarios in which you will use that functionality. You can start by asking a series of questions. Do you need to monitor customer satisfaction? If so, you can configure surveys to be sent after incidents with a certain categorization are closed. Do you need to accelerate response times for certain types of issues? If so, you can create category-based rules that will reassign, change priority, and send notifications. What terms would your customers use to search knowledge entries on your customer portal? You can create categories for those terms. Are you tracking the issues your customers care about most, and the issues that allow you to efficiently plan company resources? Categories can play a key role in generating reports that track trends and the areas that are causing high volumes of customer calls.
As with writing, brainstorming and drafting is key. You can use a white board, sticky notes, or whatever is handy. Involve as many people as possible in category brainstorming, including those who will be receiving and analyzing your reports. Be sure to consult with your support representatives…they’ll utilize categories more effectively if they are involved in the design process. You can come up with a draft list and then have the support staff try to apply the list to current open issues in their existing application; this enables you to target missing items and make adjustments to the hierarchy.
Be sure to balance the hierarchy; an extremely in-depth hierarchy makes for great reporting, but may make it difficult for support representatives as they spend more time trying to find the most applicable category. A hierarchy that is too generic can generate ineffective reports.
Darren Grigg, Product Manager and Author of “How to Make Your Boss Think You’re Working When You’re Really Just Checking Out Lisa’s Cat Channel On YouTube”
In my nearly 15 years here are iSupport Software I’ve worked with thousands of IT professionals, and have found that those who do the best with implementing any new function within iSupport are those that stay focused on their immediate needs and goals, and understand that adjustments can be easily implemented in the future. Now I’m not saying you shouldn’t consider the big picture or have a long-term vision. You just can’t get into the classic paralysis by analysis state. When designing your category structure, get your group together and whiteboard out the core categories that will allow you to leverage automated rules for routing, notifications, and service level agreement management, and will produce more organized and useful knowledge resources and reports. If vastly different groups such as IT, Facilities, and Human Resources will share the same instance, consider using the top level categories to split out each group’s categories. One advantage of iSupport over many other help desk applications is that a branch in the category tree can go down as far as five levels, so make sure that you prevent any given level from getting too many selections. It is much easier for a user to drill down into a branched category tree than it is for them to scroll through a very long list of selections. One other tip is to try not to think of every category you need in the first pass. Build out the categories your group members come up with easily and when you are in a branch where no one can think of another good node within thirty seconds, but you all feel more will be needed, just add “Unlisted” or some other value a user can select when there isn’t a good match for their issue or request. Reports will allow you to quickly identify when your Unlisted category is being used frequently enough and you can examine the associated tickets to determine what additional categories need to be added.
