I hate to say this, but "it depends". :-) Your structure above looks very straightforward and easy to understand. Some customers also have a top level item called Project, witih various categories underneath it and they use it to classify special long term projects. The one thing you have that is a little different is a Computer Problem vs. a Computer Request. I would say most times I have seen Computer as one level, then Problem/Request as a subtype and then the categories under that. However, as I said before, it depends. If this is working well for you, stick with it. There is no right or wrong way, only what works for your environment and users.
Thanks Chris, I know it is a loaded question to ask but I figured I'd ask the forum to see what others are doing.
I actually have a meeting with the Technician Leads this week to review the changes are are thinking of implementing so hopefully that will go over well.
Rather than a seperate Project Type, we have a Project Priority and hope to use that to drive part of the Change Mgmt integration.
Thanks for your feedback.
We used to get granular on type/sub-type/category but found the end user just has too much trouble getting it correct so the technician ends up changing it anyway. We simply stripped down the type and sub-type to a bare minimum of what we felt we needed to report trends on. Then we created an unnamed user for each of the TYPES which have an email address of a distribution group thatis used by the skill routing policy to notify the group. The technicians in the group will assign the ticket to themself and assign the category correctly. Not perfect but works for us.
All of this is good advice. We went the same route as Marty... we initially had the categories setup broadly, with very specific subtypes. Some of them were kind of ambiguous or "bled into" other categories so we simplified things quite a bit to keep them as straighforward as possible for the end users. Like Cris said above, it really depends on how your IT department plans on using the Help Desk module... just for desktop support or for your entire IT dept (including programmers, etc.)
Just as an example, here is ours in case you wanted to see how others structured their categories:
-Users listed here
I left out some of our business-specific things like database maintenance/changes and programming for our in-house software solutions since they're likely irrelevant to most others using TI.
John: By now, you've likely already created (and subsequently modified!) your taxonomy... Just curious what you ended up with...
We've been using TrackIt for ten years now (since v6). We initially had a Type taxonomy similar to yours (and others). Since then, we've spun things around to consider requests from our users' perspectives, rather than ours. As a result, we've ended up with a taxonomy that echoes the service catalog that we hope to publish to our users. Our upper-level Types are Account Management, Configuration, Consulting, Design, Development, Documentation, Education, Installation, Maintenance, Procurement, and Repair.
We've attracted the attention of other workgroups in our organization with our ability to report KPIs in a timely fashion, and the results we've obtained with cutting service-delivery times. As a result, we'll likely move Types to SubTypes, and create new Types of: IT Request, Facilities Management Request, etc. (where the Types divide the workgroups who access TrackIt).
There are some things that are typed in a less well-organized fashion than we'd like, so we'll likely end up with some others, as well (like, "Governance/Compliance" for our SOx- and PCI-related issues, etc.).
I'm not sure how that compares to how others are configuring Type/SubType/Category, but like Chris pointed out, perhaps others will share as this forum picks up traffic...