Best practices for helpdesk/ticketing system category trees [closed]

Question

Has anyone who's ever configured a helpdesk/ticketing system ever been through the same iterative process around creating the "right" ticket categories?

Revision 1:

• Infrastructure
  • Server
    • Citrix
    • Windows Server
    • ...
  • Desktop
    • Windows
    • Mac
    • ...
• Applications
  • App 1
    • Problem
    • Request
  • App 2
  • ...
• User
  • Password Reset
  • Locked out
  • ...

Everything seems good until you realize that you have the above functions at each company site, so you try to work a site indicator into the hierarchy, and all seems good again. Then it occurs to you that the big boss will want to know all the infrastructure tickets in aggregate, but since you've got 16 different Infrastructure buckets - one per site - you can't easily answer the question. And so on, and so on and so on.

The root issue is that we're trying to use a static hierarchy to model something which is inherently multidimensional. And the problem isn't just one of slicing and dicing the data. The more "complete" the hierarchy is, the more difficult it is for the helpdesk analyst to properly categorize each ticket ("It's a server, but it's in the NY office, so does it go under Server or NY?") The same problem existed for relational databases so eventually cubes were created. And it existed for blog posts so eventually you could tag a post with multiple categories. Tagging is the answer but most ticket tracking products don't support this notion so we're back to the static hierarchies.

Given this, I'm interested to see how people have crafted their category hierarchies so as to be as broad as possible while maintaining relevancy while not making life hard for the analysts.

Thanks

Answer 1

You're exactly right when you say the problem is you're trying to use just one category field to encode something that is inherently multi-dimensional. You need additional fields for the other dimensions.

We use IssueTrak, and it has the standard category hierarchy available. But it also has a separate field for location, so you can do reports and tallies by location, or by category, or both. There are other fields as well that can be turned on or off for your particular site. For example, you can have locations roll up into regions if you want, and call them something different than locations and regions, if you want. You can turn on departments if you want to use those. There are organizations. There are asset items, so you can associate a ticket with Server01, for example, and Server01 can have its own set of characteristics that you can report on.

Again, I think it's a mistake to try to encode the various dimensions into a hierarchy. It seems to me you need separate fields for the various types of things you might want to report on.

Answer 2

My unhelpful answer is to try to hold out for tags or to rely heavily on search.

My experience has been that the more time you put into the hierarchy and the longer the set of options becomes, the less often people actually take the time to choose the correct category. It's easier to leave it at the default or to pick the most vague category than to do the few extra seconds of work to choose the most specific one.

Answer 3

Keep them really simple and ensure that the categories reflect what you'll be reporting on. If you only want to report failures by server or by workstation, then it doesn't make sense to add large hierarchical trees that are an annoyance to navigate on every log entry.

If you aren't too fussed with reporting, don't create pre-defined categories at all. Almost for sure you'll come across stuff that doesn't fit your schema and will have to be mis-categorised because of it.

Answer 4

You are looking for a Class, category, Type and Item taxonomy. You are stuck because what's missing is some sort of configuration database (that would help with the ITEM list). The other issue is that you should use your helpdesk software to determine what services are impacted by any given issue rather than what servers have had the most downtime. If you choose a service based model, determining classes, categories, type and item gets alot easier. I recomend thinking of it as group(Class),application(category), service(type), what's actually broken(item) Also since you can use time and ticket relations to show the impact of an issue across your environment. Here's an example:

User calls in because his team cannot get to their email (CCTI might be Windows, exchange, email,client) the exchange guy takes a look at exchange and report exchange is running just fine for everyone else and traces it to a network problem. His ticket should be closed and a new ticket opened by him to get the network group to look at the infrastructure. the exchange ticket should be related to the new one (CCTI, Network, internal,connectivity,desktop) as it turns out a switch went bad, so the ticket is closed with that resolution. Now when you run an availability report against email, you should see the outage and that it was related to the network issue.

Answer 5

I have a similar dilemma to you. Currently we have 3 business units that need to use this tracker, and we use selection matrices to determine who should be notified for which category, but also who may post in which category.

Because we have staff that roam between businesses we actually use the tier 1 category for the business name, and the tier 2 for the area of support. eg:

• Alpha
  • O/S Issues
  • Application 1
  • A/V equipment
• Bravo
  • O/S Issues
  • Application 1
  • A/V equipment
• Charlie
  • O/S Issues
  • Application 1
  • A/V equipment

This schema is still pretty new, so we haven't encountered any problems with it (yet)

Two things stick out to me; re-reading your question.

1. Is this the right tracker for you? it seems to be missing the functionality you want. Perhaps it's time to find a different tool for this particular job?
2. A general rule when categorising items, the higher in the tree hierarchy, the broader the scope of the item. The direction should be from the broadest definition, to the narrowest.

Answer 6

We have a few satellite offices, but they're very small and can basically be handled by a single IT staff member. The real solution isn't tagging, but subscribing. Being able to make multiple assignments is a key feature if you really can't handle things as they are.

Another example: Launchpad offers "also affects", and pools comments into a single thread. Something like this can subscribe both NY techs and Server Techs and document the interaction that takes place (or doesn't).