[26] – Autotask Implementation Series: Statuses & Queues

Welcome to PSA Impact, your podcast for all things PSA, RMM, and MSP, with your hosts, Rayanne Buccianico and Chris Tim. Learn how to get the most out of your PSA tool and manage your business by maximizing profitability and increasing efficiency within your MSP business. Let's listen in. So, hi, everyone, and welcome to another episode of PSA Impact with your hosts, myself, Chris Tim, and my co-host, Rayanne Buccianico. Hey, Rayanne, how are you doing today?

I'm doing great today. Chris, how are you doing? I'm very well, thank you. So, Rayanne, what have we got on the agenda for today? Well, you know, I was thinking that, you know, because we're still in our series of the Autotask implementation, right, from beginning to end, and so still in the back end, I thought we should have a discussion about the difference between statuses and queues and what differentiates them, how many you should have, and, you know, how to set them up and that sort of thing.

How does that sound to you? Oh, Rayanne, you've got to stop doing this to me, man. You always want to talk about my absolute favorite subjects. So, yeah, and statuses and queues right up there at the top with my top favorites. Awesome, awesome.

So, tell me, Chris, what are your thoughts about, let's start with the queues first. When you are setting up a new implementation for Autotask or any PSA, and it's time to take a look at the queues, so tell me how you approach that and, you know, what are the must-have queues and what are the things to avoid? That's a great question, and I really think it depends on the company, right? I mean, when you first, certainly from an Autotask perspective, when you first buy the product and you log in for the first time, you're going to have a bunch of queues that are already going to be set up on the system. So, you're going to have a level one and a level two support queue, and you're going to have a bunch of others like a post-sale queue and all that kind of thing.

And the thing I find is a lot of people just leave those queues as the default. So, you know, you may have a one or two-man MSP, one or two-man band, and they'll end up running Autotask with a level one and a level two support queue. So, for companies like that, I just say, you know, it's not worth having that many queues. You want to try and keep it as simple as possible, because what's going to end up happening is a ticket's going to end up in that queue, and then it's going to get lost or it's going to get missed because somebody's not going to look at the queue or they don't have permission to access it or any of that kind of stuff. So, my theory with queues and statuses is keep it as simple as possible.

You know, call it support. So, rename it, call it support or something like that if you're a smaller company. You know, unless you have huge aspirations to grow, which hopefully you do, and you've got a, you know, dedicated level one and level two support team, and they both work out of those particular queues, then by all means have those queues. But otherwise, just keep it as simple as you possibly can. You know, I kind of have the same outlook.

Excuse me. There's plenty of time to complicate your Autotask. And, you know, so trying not to do that, like, on the first day. And one thing I was actually going to bring up, but you already mentioned it, was renaming the queue, you know, to instead of level one, level two, you know, maybe just a help desk or a support, you know, queue where the tickets can come in and they can go in. One of the things in the queues, one thing that I generally recommend for really busy service desks is like a triage queue, right, so that or a first in, first out, you know, wherever, where the tickets can land so that they can get prioritized and doled out to the proper people.

So, you know, that's probably the only real special queue that I put together. The other queue that I tend to put in is like recurring services. Not recurring services, but recurring tickets. So if you put, if you create, you know, a bunch of recurring tickets, it's really going to fill up your queue, but, you know, if you stick them all in the recurring tickets queue and then create a workflow rule to move them into the active queue, you know, a certain amount of time before they're due, it kind of keeps that queue a little cleaner. You know, so, but I'm with you about keeping, you know, as few queues as possible so that things don't get lost.

You know, if you do create one of those special queues, make sure that there's a workflow or somebody paying attention to them so that the tickets don't get missed. Absolutely, and I like what you say about the triage queue. You know, if you've got a busy service desk, it's always good to kind of have your tickets coming into a triage queue and then, you know, moving those tickets either manually or through some kind of workflow, just moving those tickets into the support queue, that kind of thing. The other reason why I really like a triage queue is that I kind of use it almost like a catch-all queue. So, you know, if you think about it, if you're getting spam or you're getting, you know, all kinds of messages coming into your support queue, what you don't want is those tickets ending up in your support queue, right, because your support queue is really what I call your working queue.

So that's really where your engineers are going to work out if they're going to know that, you know, every ticket that is in there is actionable, right? It needs actually somebody to do something on it. And when it's in the triage queue, if it's got some kind of word in it that is spam or a newsletter or something like that, you can either have the automation either close the ticket down or just have somebody manually close the ticket down, and it's then, you know, not taking the focus away from your engineers on stuff that they need to focus on by closing tickets that they don't really need to. So I think having it even as a small company, you know, even a one or two-man band MSP, and I know earlier on I said keep it simple and try and have, you know, as few queues as possible, but I definitely think having a – you may not necessarily want to call it triage, but you may want to call it catch-all and kind of have all of your tickets going in there, certainly from the automation side, and then, you know, then move the tickets from there. The other queue I would really recommend people to have for the same reason as the triage or the catch-all queue is I'd recommend people having a monitoring alert queue, and in Autotask it's built in by default anyway, and that would be a queue that, you know, all of your RMM alerts come in, whether you're using the data RMM product or whether you're using, you know, an RMM from a different vendor, but kind of have your monitoring alert queues for the exact same reason because very often they create a lot of noise, right?

So, you know, you're going to have, you know, CPU spikes are going to end up in there. You're going to have, you know, memory issues, and most of the time those kinds of issues probably are clearing themselves. So, again, you don't want to be taking focus away from your engineers to, you know, have those tickets end up in the support queue, and then they're only going to have to go and close them anyway. So – Well, I have a question about that, you know, because how are you getting your system to differentiate an actionable ticket that comes in from RMM versus, you know, something that will clear itself out? You know, is there something that can be done at the RMM level or at the service desk level that can parse that or filter it?

Yeah, so great question. So the way that certainly from a data RMM perspective and actually most RMM tools, you know, have the ability to self-heal stuff, right? So the way it works in data RMM is it will come into the RMM queue. The ticket will come in in the new status, and then if that alert gets cleared and the RMM comes in, it automatically closes that ticket down. So it closes the ticket anyway.

The only way you'll know that it's a, you know, an actionable ticket is, you know, if the alert hasn't closed and the ticket is still sitting in the monitoring alert queue, then probably it hasn't auto-healed itself or self-cleaned it or whatever you want to call it. It hasn't done that, so the ticket is still sitting there in the new status. So then you would have a workflow rule that would kind of say, hey, you know, if this ticket has been in the monitoring alert queue for more than an hour or whatever it is, then automatically move it to the support queue. And that's the other thing is I would actually move that ticket into the support queue and work on it from there. Don't go into the monitoring alert queue and then try and update it and add time to it and just leave it in that queue.

You know, make sure that the ticket is, if it's an actionable ticket, make sure it's moved into one of your actionable queues like support or whatever you want to call it. Yeah, I would totally do that too. You know, and make an internal rule, you know, in the company-wide rule that, you know, tickets in the monitoring queue should not be worked on. But, you know, if something is identified and it needs to be worked on, it needs to be moved to the support queue because that's where, first of all, most of the technicians or engineers are not even going to have access to the monitoring queue. So it has to get fired by a workflow rule in order to even move it to the other queue so that the technicians or the engineers or the help desk people, you know, can move on it and work on it.

Absolutely. And the same goes for any other queue, right, whether it's your triage queue or, you know, your recurring tickets queue, any of those sorts of things. Wherever a ticket is, you know, make sure that it's being moved to the relevant queue. So, you know, if you're a small company and your working queue is just the port or help desk or whatever you want to call it, then that's where the ticket should be worked on. If you're a bigger team and it's a level one or level two team, then, you know, it can be worked on in one of those two queues.

But whatever those working queues or focus queues, as I call them, are kind of make sure that that's where the ticket is when it's being worked on and that you're changing the status accordingly within that queue. Well, since you mentioned statuses or statuses, depending on what side of the pond you're on, tell me about, you know, how many statuses you think are relevant. And let's just talk for a minute about how they differentiate from the queues, right? You know, because we can say that the queues hold the ticket and the statuses is where in the process the ticket is. But I find that people get them confused a lot.

And do you see that, too? And how do you try to help them through that? Absolutely. And I see this all the time. I see people have a queue called new or new tickets.

And, you know, every ticket that comes in in the new status goes into the new queue. And I've actually seen people even then have a queue called in progress and they move the tickets into a queue called in progress, which the new and the in progress are already statuses. So, as you say, that's kind of the, if you like, the stage at what the ticket is at. So, the ticket's going to come in new, means no one's touched it, no one's started working on it. And as soon as you start to work on it, you're going to change the status of that queue.

So, you're going to change it into, you know, in progress or working on or whatever you want to call that status. But the ticket's still going to reside in the queue. So, I always like to think of queues almost like a kind of almost like a hospital, right, where you've got lots of doctor's rooms and the queue is like the room, the doctor's room itself, for example. And then what you've got is and your triage queue is kind of your waiting room. So, now you're waiting.

The doctor comes to call you. You go into the doctor's rooms or doctor surgery. And then he diagnoses you and he gives you a prognosis on whatever's wrong with you, right. You've got this illness. You've got that illness.

That's kind of almost like a status, right. This is where you are in your health process, if you like. So, it's kind of almost like, you know, you move from one room to another room and then you get assigned a status or you get assigned a stage of where you are in the process of your health or, you know, of your treatment, whatever the case might be. And exactly the same thing with the ticket. Comes into the waiting room, you know, somebody from the support team who's the doctor goes and fixes the ticket and goes, okay, tickets, you are now, you know, I've diagnosed the problem.

Well, I started looking at you and I've started, you know, taking my stethoscope and, you know, checking your heart and I've got my syringe out and I'm doing all these things. So, at that point, it's in progress because I'm actually working on you and fixing you. So, therefore, that's a status. But I'm still in your, as the doctor, I'm still in your doctor's rooms while you're doing that. I'm not in, you know, the waiting room or something else.

So, that's always kind of how I like to explain it is that it's the stage at which that ticket is through its lifecycle. So, you know, it goes from new to complete and it has different stages in between. So, when you're doing workflow rules, do you find that it's more effective to create a workflow rule based on the ticket status or the queue in which it is sitting in or does it just really depend on what kind of workflow rule you are developing? It depends. So, both of those two are correct and can be correct.

Normally, I would do it on a status though or a status, as you guys would say, purely because that way you can then say, you know, when a ticket changes from, you know, a new status to in progress, then do something. And that's your trigger because it's probably going to stay in the same queue through its entire lifecycle. So, you can, although you could say, you know, if it's in the triage queue and it's in the new status, then, you know, move it to a different queue. So, then you would be kind of workflowing on both of those two, you know, whereas you wouldn't want to move tickets that are closed in that queue. So, you can kind of use workflow rules to, depends on what you want to automate on, whether you want to automate on, you know, tickets that are in a particular queue or in a particular stage.

You know, getting back to where you would use a queue, for example, would be in your monitoring, sorry, your recurring tickets queue, right? Because that would then say if a ticket is in the new status and it's in the recurring tickets queue, then move it to a different queue before the ticket becomes due. So, that's where you would look at the queue. But actually, you might not do that if, for whatever reason, somebody has worked on it in that queue and is in progress. You might still say only if it's in that queue and it's in the new status, then do this.

Right. So, you know, when we're talking, when I'm talking about statuses, when you first open up Autotask, you have a bunch of statuses, you know, already set up. And, of course, you can change them and you can add to them. And I've seen some people go, you know, completely crazy with the different statuses. And I thought that, you know, gosh, one time there must have been 50 status options.

And, you know, and again, and I know that I keep saying this, don't overcomplicate these things, because somebody is going to have to make a decision. And if they have to read through 50 different options, every time they need to change the status on a ticket, because they've spent, you know, two minutes on it, they're going to spend more time trying to figure out what status it goes to next, because there may or may not be a workflow rule attached to that status. Right. So, when you're working on statuses, if you absolutely have to create an additional status, make sure that there's a really good reason for it. Right.

So, like, I have one here, and I call it in review. And that is something that we use that's between in progress and completed. Because once, you know, once everything has been done and the work has been done, it's no longer in progress. But we don't want to complete it yet, because it needs one last set of eyes on it. So, we have the status called in review, which then kicks into gear a workflow that sends it to the reviewer.

And then that reviewer can spend a minute or two taking a look at everything, making sure that everything was properly handled, you know, and then hit the complete it, you know. So, there may be some opportunity to create a status, but I would not go overboard in creating, you know, additional statuses just for the sake of having things pass through. Absolutely. And you mentioned earlier on, I was just about to say, you know, let's have a competition to see who's seen the most amounts of statuses. And you mentioned 50, and I'm like, damn, my biggest I've seen is 45.

So, I think you win. But, I mean, and honestly, 45 statuses is just crazy because, you know, the problem is somebody is going to end up picking the wrong status. I mean, I've seen somebody having one that says in progress and in process. So, they're actually almost exactly the same. But in their mind, they actually meant two completely different things.

So, in progress meant somebody was working on it. And in process meant that it had then gone to a manager in some team for processing the invoicing and that kind of stuff. So, it's like, you know, even though they happen at different stages of the ticket because they would kind of go, well, it goes in progress, it's been worked on, blah, blah, blah, blah, blah. And it goes through a bunch of other statuses. And now we need some invoices.

So, we call it in process. And I'm like, how – you know, if you're busy, if you're a really busy engineer or what have you, and you see two statuses that look exactly the same, and one is called in progress and the other is called in process, or progress as you guys would say, you know, you're going to end up getting it wrong. And if there's some workflow triggering on that, if you've picked the wrong status, it potentially could either trigger the wrong workflow or not trigger any workflow at all. So, it's really important to make sure that, you know, firstly, the statuses mean something, but also that they're not similar in name. The same thing is waiting.

You know, I've had people having two statuses. One says waiting parts and one says waiting materials. And it's like – because they didn't like the word waiting materials, so they just made a new one called waiting parts. Instead of inactivating it, they just made a new one because they liked the word waiting parts and didn't rename it, didn't do anything. And they were like, oh, well, we just told our engineers not to use the one called waiting materials.

And so, you know, you've got to really think about what it is, you know, how is that ticket going to flow through its lifecycle, right? It's going to be new, which means no one's touched it, no one's done anything to it. It's then going to be in progress, you know, so it's going to be worked on or something to that effect. And then it's probably going to be waiting for the customer or waiting materials or waiting parts or whatever the case might be, and then it's going to be closed, right? So, those are really probably the only four or five statuses that you actually need to have set up on your system.

One of the good things, though, with Autotask, you know, nowadays with the ticket categories, which we'll be talking about, you know, when we kind of focus more on the service desk side, you can actually customize the ticket categories to only show certain statuses anyway, right? So, if you've got a password reset, you can say, well, all I want to display on this ticket category is the new, in progress, and closed, and that's it, and waiting customer. You know, I don't want to show any other statuses. So, even if you did have a massively long list, which I, you know, I don't advocate doing, but if you really did want to have a massively long list, then use your ticket categories to kind of determine what queues, what statuses get seen at what times and, you know, on what kind of ticket category they get seen at. It's funny that you mention that because just as you were talking about that, I thought, I'll bet you a ticket category could solve that problem, you know, and, but no matter what you do, I think, you know, if you have a bunch of different statuses, or even if you only have a handful of them, the number one thing that you need to remember is that your people don't know what any of these things mean.

So, you have to have at least some sort of internal training session so that everybody understands, you know, what is a new status, what is an in progress status, you know, and, you know, what does completed mean? Who is the person that's going to complete that ticket? Because, you know, what if somebody accidentally hits the completed ticket, you know, and the ticket's gone, it's off in the completed land and it was really never completed. So, you know, you may have some internal review process or, you know, quality control process that you say, OK, you can never touch the completed button, right? Because that job is reserved for this department or this manager or that person.

And, you know, so you really do have to have that internal standard operating procedure so that every one of the engineers, technicians, they all are working on the same process, right? Absolutely. And, you know, the other the other reason why you wouldn't want to have so many statuses is, you know, statuses map into SLA events as well. Right. So, you know, an SLA event is which again we'll kind of cover off when we when we get onto the service side.

But, you know, that is is your first response. Right. So it's basically saying when a ticket goes from from new into, you know, some kind of other status like first response or action or whatever you want to do. That's what triggers whether you've hit or missed your SLA. And the more statuses you have, the more likely you are to have a ticket, either not have an SLA against it at all or be mapped to the wrong SLA event.

And therefore, you know, you could end up missing your SLAs all the time because it's actually mapped to the wrong event. And one of the things that talking about that, one of the things that all of us does is they actually allow you to map the new status to an SLA event. So you could take a brand new status, you know, the new status and say when a ticket first hits our service desk, we've hit our first response. And I've seen so many people have that set up. And, you know, that's all very well and good.

But that means every time a ticket comes into your service desk without you even touching it or looking at it, as far as all the tasks concerned, you've hit your first response. And, you know, to me, that's not a first response at all. Right. That's a little deceiving, I think. And it's over inflating the close rate and the SLA rate.

Right. So I agree. I don't think I don't think that any ticket with a status of new should ever be marked as having received, you know, as having hit that first response market in SLA. That just seems inherently wrong. Yeah, exactly.

And I mean, the reason it's there is is. And the reason I know some people do it is because, you know, their theory is, well, when a ticket comes into the ticketing system and we send a response back, therefore we've hit our first response. And I'm like, but that's not really the true meaning and the true definition of first response, because first response means somebody is actually working on the ticket. It doesn't mean that I've sent an email to you to say I've got your ticket. That's yes.

That's a response. And then, yes, I've responded to the customer, but I haven't actually done anything to make that response happen. So, you know, but that's the reason why it's there is is so that you could potentially kind of say, hey, you know, I can map my my SLA event to first response to new. And I had a client who called me up a few months back who actually just couldn't figure it out. And he was like, it just seems like we hit him SLAs 100 percent of the time, all the time, day in and day out.

And I knew exactly what the problem was. I went straight to his statuses and I went, yep, there's your problem. New is mapped to to first response. We undid that and his SLA started working perfectly. That makes a lot more sense.

Yeah. So, you know, I think it's really important from what we've been saying. It's kind of really important to to understand the difference between the two, between a status and a queue and understand when and where to use them. And also, you know, with both of them, just just keep it as simple as you possibly can. You know, you don't need to have 600 different queues that a ticket goes into.

And you don't need to have, you know, in my case, 45 different different statuses and in your case, 50 different statuses. You know, I think no more than then maybe five or six statuses. You really don't need any more than that. Right. Especially since now that you can control the statuses with the ticket categories.

So even if you have different lines of business, you know, where different tickets are created that have completely different types of work or statuses, you know, you can still separate them now with with ticket categories. Absolutely. So, yeah, I think this was a great topic for us to to talk about, because I think there's always a lot of confusion about this. So, you know, hopefully it's kind of shed some light on this a little bit for people. And we're going to continue this series, obviously, over the next, you know, the next few episodes.

Well, certainly probably the next 20 episodes or so. But, yeah, I mean, did you have anything else to to kind of stay on on statuses and queues? No, I think we pretty much covered it all and beat that horse to death a few times. So, well, yeah, that was a real fun topic to talk about. So.

So, right. And all that's left for me to say is your PSA is the key to your MSP success. So go out and make an impact on your world today. Thank you for joining us today on PSA Impact. We hope you've learned something and that you'll join us next time when we answer new questions posed by our listeners.