Why unknown becomes the only category your engineers ever pick

Connor: Hello, good day. I thought it was about time that I updated my ticket categorisation video. I'm going to keep the old one up. I think it's still useful. It still shows certain mechanisms inside of Halo that are good to use. However, we've slightly shifted the way we do it now. There's been a lot of enhancements since the last one, so that was a year ago. I will link the old one down below because it does kind of follow the same ideology, but with that being said, let's kind of show you what we've done, how we do it now, and kind of the reason why.

So the first thing to think about is you may not categorise at the minute, and that's quite common. A lot of MSPs we work with don't have a strict list, and this is what has led to this build path. Now I really like this build path. It's still what I come back to all the time and still the way I deploy, and it's just slightly different with a few less complexities because of enhancements in Halo.

So let me show you how we categorise tickets. We do have a categorisation map as well that I will put in the comments or the description of this video. As always, if you do enjoy this video, please do subscribe to our channel. I said it in the last one. I'm trying to hit a thousand subscribers this year, and that's only possible if you subscribe, so please do it. You'll make me happy. If you want to make me sad, don't subscribe, and then I guess we'll do that anyway. Let's jump into this.

So ticket categorisation. What is it? How does it work? Why do we do it this way? So there's two things I suppose when we talk about ticket categorisation. In my last video, I basically didn't have ticket type here. Now, the reason I didn't actually use ticket type is because on the triage action or on the claim action, there was no mechanism in the past to easily pick a ticket type or filter that ticket type list. What I mean by that is you'll see here it's a very small list, and there are changes coming in the future so I can remove Project tickets from here, but that's down the line.

But the biggest problem I always had with this is you don't want a really extensive list of tickets because it means someone has to intrinsically know what ticket do I need to log? Ends up wasting time scrolling through lists. It made the barrier to entry for new technicians a lot higher, which is kind of why I did it the old way with the query type, which was a much more condensed list.

We now just do it this way, and for the most part, most MSPs are built on day one with incident and request tickets. Now, we don't fully follow ITIL. We do when we're doing Halo ITSM builds because a lot of in-house or large in-house teams follow the ITIL methodology. But for MSPs, we kind of have a bit of this hybrid model where yes, we understand the premise, we understand the foundation, but for most teams, it's just not required to go to that extra level of ITIL in our opinion.

So first things first, you pick incident or you pick request. Ignore the other things in here, and these are simply ticket types. And then the categorisation now is much more simple. You basically say: is it admin, a backup, a hardware, a network, a security, or a software problem or request? And then this then drives a single value. So if it's hardware, what is the piece of hardware?

So if you think about this logically, we have an incident with a piece of hardware. That hardware could be ignore some of the stuff in here. Let's say dictaphone transcription pedals. I don't know why this is in here, but it is what it is. And what this allows you to do in three or six months time is you can review all of your tickets, and if thirty percent of them were faults with dictation transcription pedals, you could say right, we need to change what model we're selling to our customers. We get a lot of faults on these. Again, to reduce the overhead. And that's just a very basic example. You can go really in depth with this, reporting on what tickets take the most amount of time, what do we need to start automating, what do we need to have better process around, what tickets reopen the most? So you know if they're not first-time closures, what is that? What are they? Why have they come about?

And by having this simple level of categorisation, I think you can do a lot of stuff with it. Now the real point of the way we do this is it needs to be simple. It needs to be easy. It needs to be universally accepted within the team. The reason we build using custom fields and I'll show you the mechanisms behind this in a minute is because a lot of MSPs don't have a strong, robust list. So what we say is we use custom fields. So when you start using Halo, you can type in here. Let's just put in a Chronos and you can add it, and that means you can then add it to the SQL database.

And what I recommend to all of our partners in the first month or three months: review this, turn off the ability to add, and then you'll start to build up that foundation where you can quite easily categorise. Now, this is great if you're logging a new ticket, okay? But let's say someone logs a ticket by the self-service portal or they just ring you up, or they email in. What happens then is we have this new ticket. There is a massive problem with my PC. Robbie is a VIP. We need to get on this. But before we can start working on the ticket, we need to triage it.

Again, this is quite an industry-renowned thing to do with tickets. And all you're really doing or the mechanism behind triage is to make sure it gets to the correct person, the correct team. Now, with most MSPs we work with, I would say they're in the smaller bracket: the five to ten technicians, you know, small to medium MSPs. They're not having tickets automatically assigned to, you know, infrastructure team or level one team or, you know, whatever. It's typically the engineers on the desk. They're typically tier one. They will triage the ticket. And all we're basically doing here is saying: what ticket is it? So have they requested something, or if they logged a problem, what do we think the priority of this is?

We all know end users—it's obviously critical—but what is the priority for this ticket? And then we categorise it. So we say: oh, this is a problem with a piece of hardware. And we can type in here. Let's say it's a desktop, right? And then we know we have loads of desktop faults, and then we can dig into it further. Now, you can argue that you are missing some fundamental information here, but that's where the resolution category comes in, of how we fix the problem.

If we have fifty percent hardware incidents and fifty percent of that is user training, well, we know it's not a hardware problem. It's a user training on that piece of hardware. And then lastly, we can pick what team and agent is working on the ticket. Now, in the way we build triage, it's typically a self-association button. So it's saying: I'm taking this ticket. Which is exactly why I have the categorisation here.

I always educate our MSPs that you know, you want your engineers to be accountable for the tickets they're working on. You don't want really a dispatcher saying this is default, because typically—and again, there's a lot of speculation here—but typically your dispatcher might not be the most technical person in your business. They might just be a mechanism to route tickets to engineers. Again, we're not going to touch on dispatching today, but that's the idea. We click triage. We select the categories and away we go.

Now there's one more additional thing here, and that's request. If it's a request, we have another field appear, and this field is called request category. What are they requesting? Is it a change, install, move, onboard, remove, reset password, restore, or a testing of something? Again, driven from the ITIL ideology. The idea behind this is just so we can report on it down the line.

Now you'll notice that this looks a little bit different to these. Now that's because with request category, I actually use the built-in categorisation. The reason we've done that is because we can leverage the built-in categorisation against tickets. And I'll show you that in a minute. But what we can say is: you know, we always bill for onboardings or removal or change or you know, ad change requests. We always build for them, but resetting passwords we would include under the agreement. And by using the built-in categorisation, it allows us to have that mechanism in place.

And this behaviour here is fully replicated on new ticket. So if I was to select a request ticket, you will see we have the request category down below. I realise I've run through that all pretty quickly. I will be attaching a link to this categorisation map. Again, this is kind of what we've built out. This is kind of what we aim to do with our partners as kind of a first one build.

But the idea is from this: we have a new ticket come in. It's either an incident or it's a request. If it's a request, you'll see we have more categorisation: change, install, move, etc. And then we select a category. And again, is it admin, backup, hardware, network, security, or software? And then these are dynamic values as in you can add to that list. And this isn't an exclusive list. This is just a starting foundation. This is what is in our sandbox. This is what we typically would push or deploy into our customer's environments as just a starting foundation.

And again, this won't be applicable for everyone. That is why we make it dynamic. But I will link this down below if you're interested. You're more than welcome to have a look at it. So how do we do all of this? What is the point of using custom fields? Why don't you just use the built-in categories? Is there pros and cons to both? Which there is, but let's break it down a little bit.

So first things first, I suppose, is let's chat a little bit about how these fields are made and how they work. So what we like to leverage a lot inside of Halo is tickets and then field groups. And in here, you will see we have one called ticket categorisation. For my American viewers, I apologise that categorisation has an S, not a Z, but essentially, we have in here a bunch of fields.

And what we say very basically, using dynamic visibility, is we have category here, and within here, we have all of the categories. And within all of the categories, we then have admin, backup, etc. And then we have the category for each one of those, which contains the values. And what we simply say is: only show me the admin category custom field when the category values equals admin, okay? Only show me the hardware category when the category equals hardware, okay?

And to replicate what that looks like on a ticket: if we select admin, admin category appears. If we select backup, then the backup category appears. Now, as I mentioned, these are all custom fields. So if we go to configuration, custom objects, and custom fields, you will see that we have category at the top here, which contains all of our values. Again, single selection. This isn't a dynamic custom field as in I don't want engineers to be able to add to this list. The reason being is because we have logic built off it. By selecting one of these, something else is going to happen. By adding something in here would then break or not use that logic.

And then from there, we just have a bunch of other custom field single select with all of the information in it. And again, this is clearly something I did in testing one day. I'm just going to delete it. And now that list is cleared out. And that's what I'd recommend doing to start with: going through the list, getting it to where you want it to be, and then setting a date. As of now, we are happy as a company that our ticket categorisation for the most part is very accurate.

Please do not add "other" as a category, and please do not put "unknown" as a category. And the reason I make it dynamic is so it doesn't inhibit ticket workflow. What the last thing I want is for someone to log a ticket and go: ah, we can't work on it. There's not a category. Hence being dynamic. But as soon as you put "unknown," "unknown" becomes always. I've tried it. I've been there. It happens. I even do it myself because I'm lazy, right?

So that's how we do those ones. It's just custom fields. We make a field group, and then we basically go to our ticket types, and we then add in that group of fields in here by clicking on ADD, clicking group of fields, and we find ticket categorisation. It won't appear here because it's already on the ticket, but then we add that into the ticket.

Now, a few things to note when you're doing that. Something really nice now is the fact you can add all these defaults. So what we say is: we never want our end users to be able to see the categorisation or be able to select it on new ticket creation. That wants to be an internal mechanism. And then we say: if an engineer is ever presented with these fields, whether it's on a new ticket or just on an action, they're always required. We don't want to be able to skip over categorising the ticket. And then we simply add them all in and away we go.

But as I mentioned though, the request category one, as you'll notice, isn't a custom field. The way we handle that one is to go to tickets categorisation, and you'll find down here we have the request category, and we've just popped in here the different request categories. Again, the reason I said we do this in this build here is because under agreements, under charge types, we can define in here different categories.

So we could say that this company Traceon gets ten hours of time a month, call it block hours. And that could be simply used for onboarding of new users. It could be used for installation. You could even say that it includes onboarding. It also includes installation. It also includes removal of stuff. Everything else is therefore billable or is caught by another agreement, which is an all-inclusive agreement. I'm not going to touch too much on the contract side of it today, but just note that what I'm doing here is replicated to the customer side.

And we'll see under the billing tab down here when we do that that we're actually adding these simply to the customer record. So whenever they log a change ticket under the ticket type, it will then be caught against that correct agreement. The reason we started changing this was when we had functionality added around the triage. So when we click triage, we can now have ticket type on here, and we can now filter out tickets or more so tell it what we want to be displayed in here.

And the way we do that is simply on the action. So we have an action called ticket triage. We say by default it sets the status to be acknowledged. When we do that, I'll explain what the status is doing in a minute. And by default, it assigns it to the agent that is logging or pressing that action. It's giving the ticket to them. On the field list though, now what we can do is we have ticket type. And what we can now say is we have field value restrictions. Only show me incident or request. Again, it just makes it so much quicker and easier to log a ticket, and they're consistent.

If you was to follow it and you had, you know, service requests in here, if you had problem tickets, it gets kind of complicated for, you know, new engineers in your company to understand what needs to be selected. So again, we lower that barrier to entry. We make it as simple as possible.

And you'll see here that request category is actually not inside the categorisation here. That's because it has a few issues and bugs. I have this in manually. But again, we say: only show me the request category if the ticket type is a request. And what's great about that, and this now works properly, is when I change this here on the action, it actually fires that field and allows it to work.

In terms of a workflow perspective, we always say on our workflows for this: you must triage the ticket before it moves along in the workflow. And another slight change we made as well at some point last year was an automation to autoclaim it. All that simply does is when we make a ticket, you sometimes might say this is for me. So I can go: hey, self-assigned ticket. So I'm making this ticket and I want to work on it. I don't want to go into the pool of tickets for engineers to take.

Let's say we got a backup problem with that. And then in here, you'll see in a second, if I refresh, it'll hit the Incident Management workflow. And then it will basically move it along in the workflow automatically. I don't have to re-triage it because I've already triaged it because I made the ticket, if that makes sense. And you're now on step two of the workflow.

And again, all that automation does is it's a dummy automation, basically. Has a rule applied to it which basically says: if the agent does not include unassigned as anything, if the agent has someone assigned to it, then move it to in progress in the workflow. And that's it, basically.

I know I've not gone in full depth about how we build it all out. There's not loads of moving pieces to it. I think this now is much easier to manage than my old way of doing it. There is pros and cons to both. The last way was built because of the use case we had at the time. We had quite a complex desk. We had, you know, sixty staff with loads of different areas of the business. So the whole query type method of, you know, routing the tickets based on conversational logic as I described it was fine. But I think this way now for most MSPs is they're very happy with it. The feedback we get is pretty solid.

And you can do all sorts in here, right? You could have it as, you know, it's maybe a site visit, and then you can have all the fields start to appear, like: when is it scheduled for? What's the site date? Etc., etc. Again, this is all based on the triage action, and this is how we now build.

Short video for today. I hope that's helped you all get inside my brain a little bit, see how we triage and categorise tickets now, and understand the benefits of doing it. And if there is any questions, please let me know in the comments below, and we'll happily answer them for you. I've been Connor Fagan. Have a lovely day. Please do subscribe, and I'll speak to you all soon. Bye-bye.