Hello folks,
Documenting requests help determine how they move through an organization. Today, most ServiceDesk software utilizes three crucial layers to classify requests: categories, subcategories and items. These three key factors of requests can have a huge impact on the success of the ServiceDesk, as they will have huge impact on reporting, SLA constructions, priority degree, the paths requests take throughout the workflow and so on.
Culturally, the requester enters a category, subcategory and item, then the ServiceDesk receives the ticket and technician decides what happens next — certain tickets might be routed to certain technicians based on the category and subcategory. The technician can also determine the priority level based on this information. Organizations can set up SLAs specific to different categories of requests.
The modern-day ServiceDesk software automates most of these tasks. Today, you can easily administer rules that route and prioritize tickets based on category, subcategory and item. There is no need to waste a resource's time routing all requests to appropriate groups/technicians.
Now the big question that arises is "how many categories does an organization really need"?
Based on our experience, most of the organizations add too many categories which make the process/workflow unnecessarily complicated.
Let's take this as an example, (error, fault, major error, defect). All these words denote the same but added as various categories which make the process/workflow unnecessarily complicated. Moreover, too many categories confuse users, thus, they select one based on their best guess or randomly pick one out of annoyance. On the other hand, not enough categories can affect the organization’s ability to produce significant management reports to have a vision on continuous service improvement.
Back to the question, "how many categories does an organization really need"?
Our short answer would be:
Just enough categories to 1) enable the process/workflow and, 2) to empower the helpdesk to function optimally.
That being said the ideal number of categories should be:
1. Enough to adopt the right process flow.
2. Not more than the application can display without having a need to go to a search box.
Practically, a well-designed classification should provide approximately 10 or fewer categories submit a request (be it incident/service request, problem or change).
To shun the duplication of similar categories first, look at the existing categories to see if one can be re-used. Second, identify if an appropriate synonym already exists (e.g. fault vs defect). Finally, have control or governance to approve for adding a new category.
To close, it is easier to add categories than to cut its number after the application goes live. Therefore, start with minimal number and add as each process matures.
We would love to hear your opinions.. Cheers!