Category-driven estimated time instead of one fixed value per ticket type

Connor: I am not going to sell you something or deliver a lecture in economics but I best address the elephant in the room and that is I am wearing one of my lovely suits today. I've been out with a partner this morning and whenever we go out in the wild I will always wear a suit because we provide elegant solutions to technical problems. Little bit of marketing for you there but today I want to discuss estimated time in HaloPSA because we don't talk about it a lot to be honest. It's not something hot off the press of stuff I think we should really build in Halo and also we don't see it utilised a lot.

And that's because it kind of has a few pitfalls in the way you have to build it in and I'm going to show you what they are today. However we have provided an elegant solution around this kind of. It's a solution, elegant maybe you'd be the judge of that one but let me show you what the hell I'm talking about. So let's jump into HaloPSA.

So if you've seen this before or not you can have this little box on a ticket down here which says estimated time and the idea of this field is we can have a report that says Connor has worked four hours today. Connor worked on ten tickets and the estimated total time for those ten tickets was I don't know two and a half hours and you can look at them and go why has Connor worked more time than we think he should have worked or the flip. You know why is Connor only logged an hour worth of tickets today when we think he should have spent three hours fixing the problem?

Why is Connor rushing these tickets or not doing them properly or which is going to be the most obvious answer, why is our estimate value so far off?

So how do we do this? First of all before we get into the nitty-gritty of what we've done to make this a little bit more elegant, well on a ticket type so config tickets and ticket types you can have a defaults tab. You do have a defaults tab and further down this defaults tab you will see a field called default estimate value and what this is saying is whenever we make a ticket of this type put this time against the field estimate time on the ticket. How's a mouthful, want it?

However as you can highlight here there's a problem. What if this is a change request ticket? Well you can default that as well yeah but what if it's a change request for something quick? Oh well the estimate value is going to be the same. What if it's a change request to onboard a new user? Oh well that's going to be different. How do we control that and the problem is you can't do it with the ticket rules as far as I'm aware and you're kind of locked into this.

We've used it in the past for like onboarding and offboarding where we have a unique ticket type and we saying onboarding should take one hour but when we start talking about incidents and change requests or problems we don't really ever leverage this. I've set a default here just to demonstrate my point today but when you do that if you do add this estimate value remember to add in the field to the ticket so it's visible on the ticket of estimated time. This is just a field when you search for it you'll find it.

You can go one step further though with this and this is about another tongue twister I can already imagine it. You can also set an QB bear with me here agent ticket deals modify access roles. So what you can say is the only people who are allowed to update and modify this ticket are people with the role of whatever you say. So in my build I've said you must have the role administrator if you want to edit or change this field which is fine.

So when I go to a ticket I don't have the role administrator therefore I can't update the estimated time on the ticket. Fantastic however you'll see this says thirty minutes when originally it said fifteen on the ticket time so how does that work Connor?

Well what we've done is um I'm just going to make a ticket here test ticket and I'm going to submit it. What we've said is on triage when we select a category depending on the category update the estimated time. So currently you'll see it says fifteen minutes. When I click folder access change the work type to be I don't know IT support and press save it will still say fifteen minutes. If you wait fifteen twenty seconds or refresh the ticket you will now see that as updated to be thirty minutes.

So you can start using your categories to drive the estimated time on the tickets giving you some more data to report on. So the main question is how have we done this? Well let's take you through the fundamentals first of all. Now this is the bit I don't love however I can't think of a better way of achieving it. Leaving it AI potentially down the line but what we've done is we've made a custom object a custom table.

So config custom objects custom tables we made one called estimated time and we've made a category in here or a field which pulls all of our built-in categories which we can select. So let's say we have a Hardware desk phone of Cisco and we can type in here this should always take us no more than two minutes bear with me and then we can save it.

And what's good about this is what we then leverage in our runbook in a minute is we pull the category and we pull the time and then we pass that back to the ticket. Now you can always export all of your categories and then reimport the data into this table so if you don't have to want to go through manually every single category and add it in manually you can do a dump to Excel fill out all of the fields and estimated time pop it back in and away you go.

And the nice thing about that is if you do want to modify a few of them down the line let's say you set fifty minutes at a minimum you want to go nope ten minutes should be the new minimum you can update it and build can report it. Alternatively you can edit them in this table here and say actually disable accounts they're taking us an hour and thirty minutes as opposed to an hour. Let's update that time now so future tickets are going to be an hour and thirty estimated as opposed to an hour.

This won't go back and change the other ticket types which I think is a positive thing here but this will mean moving forward the estimate time will now be one hour and thirty minutes.

So the question is how have we tied this to the ticket? Well as you know by now we use runbooks for a bunch of wacky and wild things and this is no exception. This will be documented below in the description of this video by the way so look underneath here it will be fully written out. You will have the JSON for this so you'll be able to import this into your Halo build. You have to edit a few things to get it working but that will all be written out by the beautiful Lobby from our side. If it's wrong then it's his fault not mine.

So what we're saying here is when we triage your ticket and don't get caught up on the event this could be anything you want. When we triage the ticket run this runbook and that's because on triage we're defining the category and then the flowchart and again this will be documented. We basically say run this report run this SQL report in Halo and I'll construct it or deconstruct it a little bit.

What we're saying is taking the hour from the estimated time on that table take the minutes from the estimated time on that table and you'll see that from estimated time being our custom table um where the category is equal to um seeded um where category name is selected from category two. So in English um pull the ID of the category on the ticket.

Now what's good about that is it means if you do update your category name let's say you call it Cisco and go actually we don't just want Cisco let's put it as VOIP you could update the name of it and this will still run correctly. So we like to buy into IDs rather than names because names can change and what we do once we grab that we're saying you know grab the time so the hour and the minutes and then output that or store that in a variable called estimated time.

Then what we do in part two of this is simply update the ticket with that estimated time. It's quite simple again I won't go through all the nitty-gritty of how you configure all this. Now that'll be in the written guide if you're not familiar with how to do this but essentially that's that.

We have a ticket that we can triage. Let's make one more together to go through it. A ticket that we can triage when we select a category if I just type in here uh Hardware desk phone Cisco I can save it as IT support that will then trigger the automation because I have triaged the ticket and I didn't press F5 in it itself and that will then update this field to be estimated time.

What's good about that is you could then add that column in here so we can edit columns Service desk view show I don't know estimated time like this save and then you could filter by estimated time and go right we've got one hundred tickets in the desk. Let's start with all the quick wins just to you know clear the queue, get the backlog down, pass the high level ones to our more experienced engineers and again work as a team. Get a nice dynamic to now bring your desk down to a manageable volume.

As I mentioned at the start you can also build reports around this. So we can say you know look at Connor's um time and again this report won't fully highlight this. It's not in here but and if I just show you um this one is this the one uh no let me go to the one that says uh here this one we can say that Connor this month or let's do this week. Connor this week is supposed to have logged or targets forty hours. He's had no holiday or any sickness. He's logged four hours worth of work.

However we could add in here based on estimated time on tickets he should have worked three hours or six hours based on the tickets he got. Again this report isn't quite ready yet for human consumption. It's still in my test lab but the idea is we start looking at agent utilisation now we can leverage our utilisation against profitability and we're just starting to build a nice data warehouse of information that we can leverage as and when we need.

And that's it. We're just over ten minutes but the idea being is we can use a custom table to store all of our categories and we can set a time against it. We can have a runbook that updates a ticket with the time which we can later on leverage in many ways but mainly reporting or our service desk view to help us better manage our desk.

The next time you see me I will probably be wearing pyjamas as opposed to this lovely three piece suit but as always I appreciate you stopping by. We have just reached one thousand subscribers and that is all down to literally you so thank you so much. It really motivates me to get these videos out. I hope this helps someone out there. Any questions put them in the comments we are quite busy but I do try and get through them and as always I've been Connor Fagan. Have a beautiful day. Bye-bye for now.