Skip to main content

Service-orientated categorisation: A cause of frustration (do’s and don’ts)

(Image credit: Image Credit: Billion Photos / Shutterstock)

The TOPdesk UK consultancy team sits down once a month for a passionate debate on current hot topics, and, recently, one word was on everyone’s lips. That word causes issues for some. For example, some customers morph into a class of school children, and some consultants turn into a sheepish cover teacher when encountering the word.

That word is: categorisation.

We know that we have to categorise, but why?

The response to this question is always answered with a chorus of nodding. But digging slightly deeper inevitably reveals a crescendo of uncertainty. “Of course, we categorise our tickets!”, we often hear. But the lack of coherent sentences upon the simple question ‘why?’ suggests a lack of understanding behind what should be a straightforward process.

So, lets clear this narrative. Categories are a way of collecting data. If you are not using that data, don’t collect it. There are some simple reasons why you would collect this information:

The first is ‘reporting’. The dreaded word which strikes fear in every service desk operator and confusion in every manager. 

The second is ‘automation’. There are fields that can trigger automated processes based on the keywords chosen. These processes can be a way to close your calls consistently and efficiently or can correctly identify which SLAs (service-level agreements) need to be applied to the call.

How do you know what should and shouldn’t be a category?

There is no better time to meet this subject head-on than now. Too often, we meander between lists that are either too long (hoping to solve every reporting gap imaginable) or too short (giving an oversimplified view of the call).

So, we came up with a plan to solve this problem once and for all. To do that, we had to go back to school.

Create your categorisation narrative

Imagine you are transported back to your English class, which has been tasked with creating a story. Each person on your table must come up with the beginning, the table next to you will come up with the middle, and the one on the other side of the class will come up with the end.

Let’s look at how it pans out from a categorisation standpoint.

1. Beginning: Call type

What are the types of calls for which your customers usually ask? A customer may be reporting a malfunction or requesting some type of service. They also may ask a question, which is neither a request nor a malfunction. Finally, they may call to complain or give feedback.

Remember: Don’t use similar call types like “request for information” and “service request”. An operator may get confused about which category to choose and make the story you’re relaying inaccurate.

2. Middle: Main and subcategories

So, we are at the crunch part of the story. The scene has been set (you know what type of call is coming in) and you can determine the main content required to address the call. You have two fields that interact with each other, but they need to be approached differently.

Let’s look at the main category first:

The main category should match your service catalogue. To determine your main category, think: ‘What am I going to do with this information’? ‘Do I need to report on that word’? ‘Can I group the services at a higher level’?

Remember: Don’t repeat any call types in your categories or include assets.

Let’s look at the subcategory next:

You have your main service, now let’s try and think about any actions or tasks that can be executed. For example, what are you doing to complete the call? Remove any symptoms and solutions from the subcategory -- those go into your knowledge base.

Remember: Keep thinking about which tasks you need to report on.

Here comes the final push, giving your story a clear conclusion and that perfect punch line. It’s at this point we are going to introduce the asset (hard or soft) that is affected. It could be a laptop, a firewall, a piece of software or even a license. They should all be in the asset database with the three fields in the incident card filled. They are the object ID, summary, and object type fields. You have the freedom to define what they say and mean to you -- make sure you use them.

Remember: Not all of your assets need to be tracked. Try to group less important assets as one for reporting.

On your way to an A* in reporting

Think back to when I said that a third of the class have written the beginning, a third the middle and a third the end. When all these story parts are presented together, they’ll likely make a huge range of different stories that have a logical and consistent structure.

This is how your reporting should work as well. A tweak to a call type will change the whole meaning of the report, regardless of whether the categories are the same or not. A shift of the asset will completely change your story’s conclusion but will still make sense.

Remember: “Other” stays well clear of the story. No one likes a story where nothing happens.

Making categorisation work for you

We know that going back to school can be daunting, as can categorisation. But, by utilising this simple narrative you can achieve a comprehensive overview of your tickets. This will not only make reporting more effective and logical, but it will give you the understanding of how to best automate your processes, meaning you have the freedom to work efficiently.

Oliver Smith, service management consultant and service orientation expert, TOPdesk UK