/build/static/layout/Breadcrumb_cap_w.png

How do you organize your ticket categories?

Standardizing service desk processes often involves new ticket categories. I've worked with a lot of organizations who aligned categories to assets, which can generate useful reports. I can trade some dos and donts if you like.

Here's my question. I sometimes hear that a scheme based on IT services can be useful too, but I've yet to see a working example. Do you have one you would like to share? I'd love to trade notes. How do you organize your ticket categories?


0 Comments   [ + ] Show comments

Answers (2)

Posted by: BP_KaceAdmin 8 years ago
White Belt
0
in my experience, less is better than more when it comes to building your categorization tree.  Here is what I have used at my previous and current firm:

Break it down by:

Incident (Break/Fix)
Service Request (I need something)

Incident
      Desktop/Laptop
      Server
      Printer
      Mobile Device

Service Request
      Password Reset/Account Locked (these can be two separate categories, depending on your organization)
      Printer Move/Add/Change
      Folder/File  Move/Add/Change
      Mailbox Move/Add/Change
      PC/Laptop Move/Add/Change (ex. Moving to another user, buying a new laptop, etc)

I am not necessarily disagreeing with the last users post; however, from a reporting and trending perspective (especially if you have self service portal that is available to users)...the less complex the menu items -> the better the data and the less need for ticket clean-up from your support staff.

Hope this helps as well!



Posted by: Hobbsy 8 years ago
Red Belt
0
Whenever I cover the subject of Ticket Categorisation with customers I go back to ITIL principles. in that framework we are reminded that the purpose of the category is to capture the issue as the end user presents it to the Service Desk.

Why do we do that? because ultimately logging the ticket is part of the Incident management process and gathering information in the correct way then enables the Problem management process to provide effect Root cause analysis. 

In other words capture how the end user presents the issue and associating it with the actual issue that required fixing when you resolve the incident.

In IT we frequently want to try and categorise by predicting what we believe the issue to be, which longer term becomes ineffective.

As an example, when logging a ticket the end user says, " I have no power to my PC"

We should categorise that as Hardware::Desktop PC::No Power to PC

And resist the urge to create categories that suggest where the fault lies. In other words the user says "I have no power to my PC" they do not say:

- My Power Supply is blown
- I have not plugged it in
- The Battery is Flat
- The fuse has gone in the plug
- There is a power cut
- The mains lead is faulty
- My Desk power does not work etc etc 

But connecting the categorisation at logging of Hardware::Desktop PC::No Power to PC to a root cause of Hardware Issue::Faulty Power switch and also connecting the make model etc will provide much more powerful data from which to start preventing issues longer term.

I hope that helps


Comments:
  • Thanks, Hobbsy. That's helpful! - mhebert 8 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ