Why Connor built ticket categorisation with custom fields, not Halo's own categories

Connor: Hello, I'm going to try this for the I don't know, like 10th time I think now. I am currently full of cold, um, so I'm very nasty. I keep having coughing fits, but I'm starting to get a little bit tired of people asking me how I've done this ticket categorisation and having to type it out every time. So I thought, you know what, let's get this video out. Let's let you all know how I've done it, tell you why I've done it, and then hopefully you can all do the same thing or similar in your environment to make your life so much better.

So what are we talking about? We're talking about ticket categorisation. Now I'm going to assume if you're clicking on this video you know what ticket categorisation is. However, for those who aren't aware, the ticket categorisation is used mainly for me for two things. One is for reporting, and being able to report on your ticket data down the line is fundamentally really important. Two is obviously to get it to the right team, the right department, the right person to deal with the tickets.

So let me show you how I do it very quickly, and then I'll show you how to do it yourselves. So just to know, this is all used done by using custom fields. Um, I don't like the ticket categorisation that comes with Halo personally. I think it sucks, but you might like it. I'll show you how it's done as well in a jiffy, but first of all, ticket categorisation, you'll see it's in a nice little dropdown, um, and these are all custom fields.

So what do these do? How do these work? Well, first of all, I select the query type, okay, and this basically applies a rule. So if I click sales, you will see it sets the agent to the sales lady because unless you're a large MSP, you might only have one person who will deal with sales queries. If I select finance, it goes to the finance guy. And if I select technical, it goes to unassigned, which basically goes to the unassigned tickets for technical, and then you can obviously triage and claim the ticket accordingly.

So that's how to do that. And other, not sure what I do with that. Nothing at the minute. I think that also goes to unassigned tickets to be triaged by someone who knows what the ticket is about. Um, it's a little bit more deeper than that, but I'll show you how this works.

So if I select technical and let's say somebody rings up and says, please, can you create Ben a user in Microsoft 365? Okay, that is what they say on the phone. So they go, yep, let me just make you a ticket. Let me just categorise it now. So this is a technical request. Yep. What is the request type? Sorry, there's going to be so many jump cuts because I just keep coughing. Yeah, just we'll get through this together.

Okay, what is a request type? Well, this is to create Ben a new user Office 365. This is probably onboarding the user, right? What is the subcategory? Well, you'll see this is a SaaS product, and it is Microsoft 365. And you'll see in the bottom right-hand side now this is set a rule to set change ticket type. This is because most MSPs will categorise change or onboardings as billable work. So I set this to be a change ticket where it will have different billing rates applied.

Um, I won't touch on that now, but essentially that is why that rule has applied here. You'll also notice when I selected onboard this tick box appeared, which basically says, is this a new starter? So the person on the phone would then see this tick box and go, oh, it's Ben, a new starter? You'd think so, right? But stay with me. So then select yes.

Now typically I'm running at 100%, so it would appear nice and neatly here, but I'm zoomed in for your benefit. And then it asks a few more questions, okay? What is their first name? Well, we've established it's Ben. Is that Ben or Benjamin? What is their last name? Okay, it's Castle. What is their employee ID? And let's do one, two, three. Again, this could be for you, this could be department, this could be what groups that they need to be in an Microsoft 365. You can really bake this to benefit you and to benefit your MSP. And then finally, what is their start date? So their start date is the 1st of December. And then we go ahead and click submit.

Now the reason I think ticket categorisation is really important is when it comes down to recruitment and training because let's say this for instance, at the minute, okay, the helpdesk manager goes, look, we're really falling behind in SLAs. We can't keep up with the ticket intake. We need to do something about this. Can we hire some more staff? The first question needs to be, what type of staff member do we need? Do we need a level one? A level two? An on-site engineer? Do we need a remote engineer? Level three? What do we need?

And without having this data, it becomes very difficult. It's kind of finger in the air work, right? Oh, well, level three obviously because they do everything. Um, but be able to categorise and obviously report on this is fundamentally so important to me.

So let's say, for instance, you did a report every quarter and you notice that 90% of your tickets were already requests and there were always password reset requests. You can then drill into what application and let's say it was Microsoft 365 user business could say, wait, actually we don't need to hire someone. We need to roll out self-service and give the customers the ability to reset their password, reducing our ticket volume.

Or it could be, let's say you have loads of incidents for a faulty piece of hardware, and that hardware is always a laptop. You would then look at the laptop model and go by the asset you tagged with the ticket and go, hang on a minute, we've had 80 tickets this year all for a Dell Optiplex 380. We need to stop buying them. They're having too much RMAs on them. And again, having this data can really help you.

Or it could be you report on it and say, right, what are the longest tickets we have? And you could find that they're always, I don't know, when a customer gets phished, the remedial work always takes way too much time. So you need to go, right, we need to fund training for our guys to help them through the remedial stage, but also give training to our customers to reduce that workload.

So again, by having this data at the start of your journey is so important, and you can always expand in this and grow on it. Um, a few things to note though. I would try and keep this as clean and as simple as possible. Don't overbake it. So you could then have hardware category, what type of hardware categories? Memory, CPU, hard drive, yeah, okay. What was the fault and the problem? You have then is it then takes too long to log a ticket, and people don't log tickets properly because they get bored after the 15th question.

You need data that you can use. Don't overdo it though, and it is kind of a hard juggling that depends on your team, depends on the type of tickets you get. I can't give you the answers to that unfortunately. It really comes down to you and how you work. And I say always, you know, include your team when you're doing this. Make them have the input in it. Do you mind adding one more step? And do you think it's too much?

Really bake it to how your company work and how your team feel categorising tickets in this way. So that is how I do it. The way Halo wants you to do it is by going to configuration, going to categorisation, and then building out these category types here. So out of the box you have category, which is all this predefined information, and this is only really three layers deep.

So you have account, administration, folder access, and then something else. Now I don't really like this, um, and I'll show you why in a second. And then you have another categorisation for resolution, which I actually kind of keep here because resolutions can be the same across many different things. Um, and this is kind of a nice list that you can grow on. But again, you can do this with a custom field if you desire. Completely depends on how you want to work.

I'm just going to add that category one just to show you how it looks adjacent to how I do mine. So I'm just going to add the custom field category here. It's going to jump in and create a new ticket. So this already is one of the problems I hate with this is the fact that it will always expand beyond the page. Now obviously I'm zoomed in, but even at 100%, when I expand the box, it then goes off the page.

So you've then got to scroll down, and then if you want to scroll back up, sometimes you'll scroll the page. And I just don't like it. And also it's kind of like a long list where you kind of have to be, you know, it's a small cursor and it's, I just don't like it. I just don't think it flows very nicely.

Yes, you can type in here. He says if I could type, you can type in here to find it. Um, but again, if the same thing is in multiple categories, you could mistakenly click on one, whereas with my flow you can't, because it kind of drives in a certain way. Again, if you like this, it is kind of clean, it is kind of slick. You can always use it. I just prefer doing it with custom fields.

So let me show you how I do it. First of all, we go to configuration. We go all the way down to custom objects. We click custom fields and we make sure we're on the entity ticket. I'm going to go to the second page because I've made quite a lot of custom fields now.

Just quickly, my name is Connor, and there is a CF at the start of these. These aren't Connor's custom fields. CF actually stands for custom field. I used to prefix all of my custom fields when I was building this with CF, and I'd end up with CFCF, which was particularly annoying, um, because when I was building, I wanted to know what was predefined already and what I was making. Slight tangent, but little story for you.

So go ahead and just grab a quick print screen of all of these from category type all the way down. If you've done that, we'll move on and I'll show you what each of them kind of contains very quickly.

So category is incident and request. Subcategory would be hardware, infrastructure, of service, network, SaaS, et cetera. Software category contains a list of software. Hardware category contains a list of hardware. SaaS contains a list of SaaS products. IaaS the same. Security category I put in here, you know, virus, ransomware, phishing.

We have event type, which is fault and offline. Request type, which is what type of request it's going to be. Query type, which is obviously the route. Now these are slightly out of order in my environment because I've built these on top of each other, if that makes sense. But you might do this in a more linear way. I'll show you what the linear way is in a minute.

And again a few more other ones. The only one that's different here is, is this a new starter? And I've made this a check box, either true or false. Basically, once you've made all of your categories—and this could be as many or as few as you like, you can always add to this down the road—you then need to go to your ticket type, incident, and go to field lists. And PSA, when I first made this, I added in all of my custom fields, like I did with category, to the incident ticket, and then wanted another ticket type, and then realised I had to go and do all the work again and started crying a little bit.

I'm here to help you not have this problem. Something I didn't realise for the first six months in Halo is there is this tiny little click here button. Let's just zoom in for you here. Click here. This allows you to make groups of custom fields. Go figure, who knew?

If you click here, you can then click new in the top right. You can type in a field group name and a group header, and then you can add in all of your fields. I recommend you take a print screen now because this is the order, or this is the flow of when the custom fields appear in my environment.

And then we need to talk about how they appear dynamically. Key word there is dynamic. So let's say we have, I don't know, say category. Okay, category is purely for technical categories. So if I just go back very quickly to CF category, which is here, CF category type incident or request. Well, I say these are for technical queries rather than, you know, have a sales incident. You might do, but not in this environment.

I say that the category type only appears when they select the query type of technical. I'll explain a little bit more how that works.

So if we had the custom field hardware category, I only want the hardware category options to appear when they select hardware under the list of faults. So you'll see here that the subcategory hardware is selected. If I just demonstrate on this screen here, so we have technical incident. Subcategory here, so when they select hardware in the subcategory, then the hardware category appears.

So what we say is, when they select, so CF subcategory, when they select hardware, and only hardware, then the hardware category list will then appear. And I say that to the end user or your customers, when they log this on the self-service portal, they don't have the option to fill these in. I think most customers won't enjoy doing this as a task. Not like any of us enjoy doing it, but I think your customers will hate it, particularly.

But I'll show you how we handle that in a second. Um, and the other things are, you know, agent warn if it's empty and then show in the ticket information that was in that side panel. That is where that appears. If you wanted to have all of your categorisation to be in a separate tab, simply click separate tab, and that is essentially it.

So everything here is driven by dynamic field visibility. The same network category only appears when you select network. Um, and the benefit of it being in a group is because, well, let's say majority of your tickets don't actually come in over the phone. They always come in via email or from the self-service portal, and then on the first stage of claim, you'll need to triage out a ticket. So you'll need to basically assign the sales or technical categories, or whatever you desire, um, at this level here.

Now, if you make them fields manually, you would now have to go to the claim action and replicate all of that work you've done. The benefit of doing it in a group is the fact you can go to the claim action and you can simply do the following. You can click add group of fields, and mine's called ticket categorisation, and click save, and it's done.

So you can have that triage stay in straight away. So using it in groups is, I think, amazing, and I learned this. The hardware I did it manually first, and then regretted it. But essentially that is that.

Um, I'm going to end the video there because I'm struggling to get this last sentence out, um, but essentially I use custom fields to drive my tickets. I have rules that apply to basic keywords. Um, I'll show you. It's a bit easier. I have rules that apply when they select query type. You'll see that the rule has matched, and again, this does work at a triage state, just in case you were wondering.

Click sales and click save, and just do a quick refresh. You will see that it has still set the sales ticket as sales, and it has assigned it to the sales lady. And but in reality, um, you wouldn't be triaging or claiming the ticket if it wasn't in your department. So I add some quick buttons up here to pass it to the sales team or the finance team, and that is for another video.

I hope we've got through this together. I hope this has been useful. I apologise for how rough this has been, um. I tried this about 10 times, and this is the final take. I give up. Um, but yeah, I hope this helps.

I use custom fields to drive ticket categorisation. I think it is really important you do it. I'm not saying you need to get it right first time. Ticket categorisation is iteration after iteration, but start with something. Only you and your company will know what you need to categorise on. Don't try and implement a turnkey solution from somewhere like ConnectWise. They have an endless list. There's going to be things in there you're never going to click. It's going to be awful for your team to navigate it because there's too many things.

Try and build this up on things that your team do and how your team work. My guideline is here. You can see how I've done it. Um, this is a Renada sandbox. You can request from Halo, and this is how it's built. But this isn't a turnkey solution. Again, for MSPs, this is a thought-provoking state to say, right, we can categorise in this way. What do we need to be capturing at ticket creation or resolution?

I've been Connor. It's been a pleasure. Have a lovely weekend. See you guys soon. Bye-bye.