John Stimson, who has had more experience with categories then perhaps anyone on the planet, has penned this master piece.
_________
When Daren mentioned the topic of categories, my initial reaction was, “Oh my gosh, where do you start?” After giving it quite a bit of thought, I realized that this was also probably the reaction of many of our customers.
When I’m on the phone or long in the past when I was on site, the previously gathered information, general conversation, and line of questioning drove the entire discussion. Writing it out on paper without interaction is a different task entirely. It could be a bit overwhelming even if you think on it too much, but really it couldn’t be easier.
Let’s first understand what we can do with iSupport. We can have five levels of categorization but only one level is required. We can also add dynamic custom fields to each one of the selections of those categories, to capture still further granular detail. (Technically categories can even be turned off, but we are here to talk categories, so let’s presume we will be using them.)
Categories are used as a focal point throughout iSupport. They touch Incidents of course, but also knowledge entries, problems, changes, the Social Client, permissions, etc., so giving them a fair amount of thought is a very wise thing to do.
In short, that is a ton of choices…potentially too many choices. I recommend keeping it to three levels or less as much as possible. Think about your daily life. Many tasks that involve more than three choices aren’t tasks that you want to do, and most start to look for shortcuts to do them faster. Now as a technician who lives in categorization all day, you’ll definitely want it quick an efficient. (I’ve yet to see a support desk pay their folks by the hour on a per ticket basis—there is usually no incentive to spend more time on a ticket than necessary. It’s typically driven by volume and staffing, which typically is high volume and minimal staffing. So efficiently is very important.) Scrolling through a lengthy list to find the entry you want, or to pick the best fit, isn’t necessarily getting the issue solved any faster, but may add frustration and contempt. No one wants that.
You’ll next want to consider what you want to categorize and why. Although you’ll want to keep categorization short for technicians, rarely are technicians the ones who even remotely care about categorization. Your customers don’t really care either; they just want a quick solution to their problem. This translates into a quick and easily-submitted issue via the Social Client or a logical arrangement of self-help and knowledge entries.
The ones who typically care are those trying to get information back out of the system by way of reporting, knowledge, and historical searches. Typically these are folks at pay levels where “I don’t know…” isn’t an acceptable answer. However, what they won’t know now they’ll want later. Can anyone really say today what will be needed tomorrow?
The best category structures are ones where the organization’s structure, policies, practices, and culture are taken into account. What has been cared about in the past? Why? What future direction is the organization headed? To get answers to these questions, you need to get the opinion of others. This is where it can get a bit tricky; I’ve witnessed near fistfights over discussions of categories. People are passionate over their opinions!
Talk independently to senior technicians; get their thoughts on categorization, what has been successful, and what has failed in the past. Then talk to the folks ‘upstairs’ who will be looking for reports, metrics, KPIs, etc. from the data that will be captured. What is important to them? Then (and this is really different for every organization), look around to the parts of your organization that you haven’t talked to but frequently or even occasionally interact with. Could they gain efficiencies by tracking their data? Exchanging data easily between the departments benefits the entire organization. What starts as typical IT data tracking finds its way over to HR, then to facilities, operations, manufacturing, security, etc. Each group has their own needs which won’t fit into a neat and tidy IT categorization. A conversation with and consideration of these other groups, who may never plan today to use a tracking system like iSupport, may go miles later when they see some advantages to the automation and shared data resources. Reaching out at the beginning will aid in that potential integration in the future. (Not to mention hopefully recognition to you who thought to reach out to the other groups!)
This is the interaction I mentioned. This is all in an effort to shape and build the structure. Normally at this stage a picture of the category tree should start to clarify. Start to build it based on the consolidated notes of the various conversations.
Get going now, as you have to start somewhere! It’s easy; create one entry and then another. Build the category tree from there, one step at a time. Although they should be used sparingly, use a few generalized categories. The dreaded ‘Other’ category—what does that mean? It’s a choice that is essentially an undefined end category. These aren’t good for reporting or finding an answer but are invaluable, especially in the beginning, to find out what has been missed or overlooked. Create an alert or rule that notifies you every time this categorization choice is used, evaluate the issue that used the category, determine what the best end category choice should have been and then add it to your category structure. Miscellaneous events happen and should be classified but those events should be rare.
Is a category structure set in stone? No! It’s easy to adjust and change a category structure in iSupport. A category structure should be reviewed regularly. Remove category choices that haven’t been used in the last year or so. Keep the number of available choices as tight and concise as possible. Check back with the folks you originally spoke with. Find out what is working and what isn’t. If it isn’t used it isn’t working. If it isn’t getting used for aiding in getting data and metrics out of the captured data, change it! Technology and business needs change, and the category structure needs to evolve and match those changes. This is one of the key reasons why simply bringing in an ‘old’ category structure from a legacy system isn’t a good idea. It is doubtfully working now and hasn’t been reviewed lately, which in part is likely why the entire system is getting replaced. Take the opportunity to start anew.
Earlier I mentioned that your customer may not be concerned about your category structure, but you can gain efficiencies if you exposed some of the category structure on your Social Client. This should help the initial time taken to triage an issue, speeding the issue into the right hands, or even allowing the customer to find the solution themselves in your external knowledge base. Keep in mind that your customers may not use the same terminology and lingo as your support group does, so adjust your category labels to benefit the terminology of both customers and technicians.
Category structures will rarely be perfect and will differ from organization to organization. Although ‘canned’ ones can be great to offer a proof of concept in a product’s evaluation stage and even get the production deployment going, the resulting constant revision should shape it into something very unique to your specific organization. There isn’t even an industry standard; if there where, what differs the product or service you offer from that of your competitors? To remain competitive you need to be constantly changing and adapting to the needs of your customers. Your category structure should be just as dynamic.
Give categorization thought, but not too much thought as it will change. Get going—it’s easy.
