Best practice for categories & subcategories

I'm interested to see how other firms have their categories and subcategories. I'll start....

Category (What you want to achieve)

Subcategory (The particular application, asset, request you are looking to achieve)

  

Top Replies

Parents
  • Ours doesn't look too different from yours, and I like the way you frame category as "what you want to achieve!"

    This may be blasphemy, but I'm going to offer that using categories and custom fields to capture information that may be useful in the future is a fool's errand.  It will be exceedingly rare that highly specific data capture will provide useful at the time you're actually trying to solve a complex problem.  

    For example, you may have a Network category, and then subcategories for Routers, Switches, WiFi, and Cabling.  If they're all handled by the same team, what's the point?  "Someday I might want to know how many tickets we have related to our switching infrastructure!"  Nah, probably not, and you can always semi-manually mine for this information if you really need it.  So start with Network, and you'll know if you need subcategories when you actually need them.

    Focus instead on process and what you need to measure today.  You need tickets routed to the right teams, and give your customers a means to get you the right information to make this happen, as easily as humanly possible.  Start with as small of a list of categories as possible, and only add when you know you need to - because your process requires it.  Use resolution codes that are qualitative and related to your processes, not the fixes (e.g. "replaced hard drive" is too specific and pointless; "permanently solved" vs "workaround" are more useful).

    Sorry, not trying to sound like I'm lecturing.  It's just that we as IT people love to categorize things to the extreme.  This can create a tremendous amount of noise, incorrect data, and wastes the team's time.  I think that your approach looks pretty good from what you shared. 

Reply
  • Ours doesn't look too different from yours, and I like the way you frame category as "what you want to achieve!"

    This may be blasphemy, but I'm going to offer that using categories and custom fields to capture information that may be useful in the future is a fool's errand.  It will be exceedingly rare that highly specific data capture will provide useful at the time you're actually trying to solve a complex problem.  

    For example, you may have a Network category, and then subcategories for Routers, Switches, WiFi, and Cabling.  If they're all handled by the same team, what's the point?  "Someday I might want to know how many tickets we have related to our switching infrastructure!"  Nah, probably not, and you can always semi-manually mine for this information if you really need it.  So start with Network, and you'll know if you need subcategories when you actually need them.

    Focus instead on process and what you need to measure today.  You need tickets routed to the right teams, and give your customers a means to get you the right information to make this happen, as easily as humanly possible.  Start with as small of a list of categories as possible, and only add when you know you need to - because your process requires it.  Use resolution codes that are qualitative and related to your processes, not the fixes (e.g. "replaced hard drive" is too specific and pointless; "permanently solved" vs "workaround" are more useful).

    Sorry, not trying to sound like I'm lecturing.  It's just that we as IT people love to categorize things to the extreme.  This can create a tremendous amount of noise, incorrect data, and wastes the team's time.  I think that your approach looks pretty good from what you shared. 

Children
No Data