[37] – Autotask Implementation Series: Service Desk – 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. 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?

I'm doing great today. How are you doing today? Very well, thank you. The sun is shining and it's nice and light outside, so all is good in my world. So what are we going to talk about today?

Well, we've gone through quite a lot of the settings as far as implementations are concerned. And I know right in the beginning in one of the conversations we had, we talked all about the back-end settings and we brought up queues and statuses and all those kind of things. So in this episode today, we're going to talk a little bit around the service desk, but specifically we're going to talk more about queues. And really, I wanted to kind of get your take on how you think queues should be used and if you've got any real-world scenarios on how many queues people should have and why they should have those queues and what they should call them and all that kind of good stuff. Okay.

So service delivery, one of my favorite topics, and I'm sure that it's one of yours, right? Absolutely. Of course, it's one of my favorite topics. So thank you for bringing this up. Yes.

One of the first things that you've got to do when you're setting up your service desk is determine the queues and who is going to work the queues, right? So when a ticket is created, it has to be assigned to a queue of some sort. And my theory is, and I'm anxious to hear, because we didn't really discuss this a great deal before we started recording today, so I'm anxious to hear your take on it. Okay. So fewer is better, right?

The fewer queues you have, the more organized your company can be. And every queue should have a purpose. There should not be more than one general working queue. And it's fine if you have, let's say you have 40 techs in your MSP. You might have a Level 1 queue, a Level 2 queue, and a Level 3 queue, and they have very different jobs and very different tasks assigned there.

So my base queues, I generally have a help desk queue of some sort, like a Level 1, Level 2, or even just a help desk queue if you're a fairly small MSP. I also generally have a triage queue, and that's like a catch-all place, right, that when the tickets come in, they might come in through the email parser, they might come in through the client portal, they might come in, they might be entered in by, you know, somebody in the office. And that's an area where the tickets are going to sit until they are specifically assigned to somebody. The tech should go in and check out the triage queue and start picking their tickets and assign it to themselves. There's a couple of queues you can't get rid of.

You've got the post-sale queue, you know, so when you're closing out opportunities, the tickets land in the post-sale queue. And one of the first things I do is create a workflow rule to get it out of the post-sale queue and over to the person who's going to work on it. And then I might also have a recurring tickets queue, although there's an updated feature inside Autotask that, you know, actually does away with the need for the recurring tickets queue. So what are your thoughts on it? I know I've been talking for like the last few minutes.

Well, I was just going to say, wow, that was a long answer. Sorry. That's okay. So I guess before we start, one of the things I think that confuses a lot of people is what is a queue? Why do we need a queue or what's it there for, you know?

And my take on that is it's kind of, I always like to refer to it as, you know, some kind of holding area or some buckets or something. So it's like, you know, issues come in, you put them all into a big bucket or into an in tray or whatever you want to call it. And think about that as a queue. So it's a holding area where you're going to hold these tickets, or not necessarily a holding area, but you're also going to work in those holding areas. So what I like to use the analogy of in this would be, you know, something very similar to a hospital.

Right. And you mentioned a triage queue earlier on. So, you know, you guys over there have, you know, I think you call it the ER or the emergency room over here. We call it A&E, you know, which is accidents and emergency. You know, but I think that the concept of them is pretty much the same.

You know, you walk in, there's a reception desk and you sit in a massive waiting room, right, until your turn is called. And then, you know, either a nurse or a doctor or somebody comes in and takes you from the holding area and takes you into another holding area, which is the doctor's room. Right. So that's why I call them holding areas, because you're still going to kind of be in the doctor's room while they're talking to you, while they're diagnosing your problem, while they're doing whatever. You're in a different room.

So if you think about queues as different rooms that you might put things into for four different reasons and, you know, the triage queue is really there as the main holding area. So as tickets come in from the email processor, they're going to sit in this holding area, they're going to sit in this triage queue. And then somebody, either some kind of automation, you know, where we can automate certain things within the ticket or a person, you know, whether that be a dispatcher or whether it's somebody on the service delivery team, is actually going to say, OK, this ticket needs to go to Rayanne, this ticket needs to go to Chris. But they're going to put them into the, you know, into a queue that we both are working on. So if you and I are both working in the service, like level one team, for example, then they might drop that into the level one team and either assign it to either one of us or just drop it in there.

And one of us can go and grab it from from there. So again, using that same analogy, that would be like, OK, you need to go to x-ray. So you go to x-ray and you sit in another waiting room until somebody, one of the x-ray people, what do they call them, radiographers or what have you, they'll come and pick you up and say, OK, I'm going to x-ray you today. And then maybe there's somebody else sitting in the x-ray room and another x-ray person comes and picks them up and x-rays them. And that's that's the concept of the kind of the service desk and how queues work.

So with the x-ray technician, you kind of tie in another portion of the service desk in the service delivery, right? So the person sitting in the room and here comes the x-ray technician because they saw that that person was sitting in their queue. So they went and they hopped in and they picked it up and maybe they changed the status to taken for x-ray. Right. So now what we have is the purpose of the status, you know, while working alongside with the queue, because it might not actually leave the queue, but the status has changed.

And so while the x-ray person has taken the person out and is running the x-ray, then you can look at the ticket and say, oh, OK, Chris is out for an x-ray right now. And then when the x-ray is completed, you know, it might be handed off to the next task in line. And so therefore, the status would be back into waiting on doctor. But, you know, we're still talking about health care here. But so let's tie this in to like a real live MSP service delivery and how how they might be using these different queues in their company.

Right. So one of the ones that I always do, let's say you win an opportunity. Right. So you get the opportunity. You've got the quote.

You send the quote out. Customer says, this looks great. Now you go through the one opportunity wizard. And now what's going to happen is you're going to create a ticket and that ticket's going to land in the post sale queue. Right.

So when I create that ticket, I do a couple of things. I have a work type called procurement, purchasing and procurement or something very similar to that. And that's because that's where I want this ticket to go next is I want that to go to the purchasing person. And then we set up a workflow rule, pull it out of post sale queue and send it over to purchasing if the work type is purchasing and it came from the from the wizard. So what are some other real life scenarios that MSPs will use their queues for?

What do you normally set up? So and that's a great question. So at the beginning, when you started talking about fewer is more or less is more, the way I recommend people to do it is pretty much the same as you do. So to have a triage queue and that would be your holding queue. I also always recommend that somebody has some kind of of working queue and I call that a working queue as in, you know, level one, level two or support.

And the reason I call it a working queue is tickets should not be worked on inside the triage queue. Right. So likewise, you're not going to get the x-ray technician coming to do an x-ray while you're sitting in the main waiting room of of the ER or in A&E. You're going to actually go to another room where they're going to work on you or, you know, the doctor is not going to come with his stethoscope and kind of, you know, listen to your your chest or your heart or something whilst you're sitting in the waiting room. Well, at least that doesn't happen in most countries.

I don't know if it might happen in some countries, but, you know, so so I would always say when a ticket comes in, make sure it always leaves that queue. Make sure, you know, the the the triage queue is only there as a as a holding area and then it moves to a different queue and you work on it from there. Now, you were then asking about, you know, how do a lot of MSPs do this? And I would say every single ticket that comes in should always hit that queue first, should always hit the triage queue, even if it's something, you know, and I would almost always even say that potentially even things like monitoring alerts should actually go into that queue as well. And the reason being is because a lot of that stuff is noise.

Right. So a lot of the stuff's going to go in the triage queue and it's going to heal itself and it's going to close the ticket and it's gone. Right. But what you don't want to happen is you don't want to have those monitoring alerts coming into your working queue, coming into a level one or a support queue, because if it's something that is going to self-heal, like it's a CPU that's spiked and for whatever reason you've you've got an alert generated, what's going to end up happening is your engineers are going to focus on that. You know, they're going to spend 15 minutes, you know, figuring out why the CPU is spiking, you know, and then the RMM is going to go clear the alert and they've wasted all that time figuring it out or, you know, in some scenarios, and I've actually been in a scenario with an MSP where a monitoring alert that's coming to the support queue and the support team spends 25 minutes talking about, you know, why it should or shouldn't be alerting at certain thresholds.

And, you know, that's just wasting a lot of time. But it's because they're seeing the ticket in there and they they're focusing on it rather than focusing on the stuff that they really should be working on. So, you know, my recommendation always for an MSP is make sure that the queues that you have are meaningful, that they actually mean something, you know, like if you've got like you were saying about the post-sale, so if you've got a post-sale ticket, either put it into a queue called post-sale because that's the queue that somebody is going to work into to actually look at that ticket or, you know, move it to a sales queue or whatever the whatever the case might be. But, you know, make sure that the queues have meaningful names, make sure that the people that should be looking at those queues are looking at them and try and automate as much as you possibly can in and out of those queues. Right.

So, I mean, I totally agree with everything that you just said. And think about like best practices. Right. So let's say every ticket that gets created lands in the triage queue, every ticket, because you want to do things in a more uniform and standardized fashion. Everything goes into the triage queue, then you can set up your workflow rules and you can base it on things like, you know, issue types and priorities and set up standardized procedures for moving those tickets out.

Right. So like you were talking about the RMM and, you know, the monitoring alert that comes in. Let's say that it doesn't heal itself and it's been sitting there for 45 minutes, then something might really be wrong. And so maybe you set up a workflow rule to trigger something like that to notify somebody that, hey, this this monitoring alert has not itself healed. Maybe now is the time for somebody to take a look at it.

So, yeah, I guess what I'm trying to say here is that we've got to find a way to standardize because if you're an MSP and you're trying to grow and you're trying to scale, one thing you've got to do is automate and standardize, because if there's a human being that's, you know, in charge of looking at every ticket or if there's some manual process in what you're doing, it's going to break down at some point. Maybe not when you're at your current stage, but as you start to grow, you're going to outgrow those manual processes, believe me. Yeah, absolutely. You know, and we were talking about earlier on about sort of the less is more. And I know, you know, I sort of said to have, you know, meaningful cues, but most of the MSPs, when I'm talking to them, I whittle that down to maybe five or six cues at an absolute maximum.

And I think that's probably about right for the majority of certainly, you know, smaller MSPs and because, you know, you really don't need to have a level one and a level two cue if your engineers are all doing the same work. If they're all doing level one and level two work, then you don't need to have a cue called level one and level two. You really only need that, you know, if the people are dedicated to doing that type of work. So, you know, the same thing as in a hospital, bringing it back to that analogy is you wouldn't have a chiropractor work out of the same room as a as an x-ray technician. Right.

They would have their own their own rooms, their own cues effectively, you know. And so in that respect, you would need to have, you know, different cues. But, you know, if you had the scenario where all of your your engineers were all working on level one and level two, so, you know, you had the chiropractor and the x-ray technician both doing the same kind of work, then potentially you could just have them being in the same room. So you need to think about it like that. In every scenario you do is what are my guys doing?

Are they dedicated to doing a level two role? And if they are, then have a level two cue and don't give access to your level one guys. If it's just the flat structure where everyone's doing level one and level two or level three, whatever it is, and everyone's just jumping in and working on any of the support tickets, then just have one cue called support or whatever you want to call it. It doesn't really matter. But, you know, and in that instance, you would only just need to have that one cue.

Yeah, and I think it's important to note that you're probably not going to be running any reports based on the actual cue, right? Because again, let's remember what the cue is. The tickets are standing in line waiting to be worked on. That's literally the definition of a cue, right? You're standing in line.

So it's not going to affect the amount that the customer is invoiced. You know, it's not going to affect the billing rate at all. And it's hardly going to affect the reporting. You know, maybe if you're looking at your service desk widgets and you only want to look at the level two cue because the level one cue is that's a different department. So, you know, really think about and what you said about if everybody's doing the same work, you don't need to split out the cues.

But if you've got, you know, high end engineers and you don't want them touching, you know, the help desk tickets, you know, when just because they're bored or they have nothing better to do, you just don't want them touching those tickets, then separate the cue. Keep those engineers out of the help desk and likewise, keep your help desk people out of the level three stuff. If you if you have technicians or engineers with very, very different roles and you don't want them ever crossing that magical double yellow line, then then, yes, split up the cues and get them out and keep them out of places where they don't belong. Keep the salespeople out of, you know, the help desk queue by giving the salespeople their own queue, that sort of thing. So pretty much what you're saying.

Pretty much. And and that's, again, the reason why I think, you know, everything should come into a triage queue, because there are going to be certain things that, you know, if you've got one queue for support and you've got level two guys, they don't need to be bogged down with or worried about, you know, tickets that a CPU is spiking. So why put it into that queue, right? Put it into a triage queue and don't give anyone access to that queue except the people who need it. So except the people who are actually going to connect into that queue and are going to, you know, move the tickets around into different queues.

And that's always why I say keep them keep the tickets in a separate queue and keep your working queues to the people that need to see them and the stuff that people don't need to see or shouldn't be bothered with seeing or, you know, bogged down with with what information is in there. Then keep them out of those queues, as you say, and just, you know, just let them see the information or the tickets in the queues that they need to have access to. So real life, you know, scenario, right? Ticket comes in. It's it's assigned to the help desk and somebody picks it up.

And so they start working on the ticket and then they realize that they need to, you know, they need to ask for they they need to get some sort of permission from the customer in order to buy something. Now, do they change the queue and, you know, move it into a different waiting for customer queue? And, you know, is it necessary to do that to get it out of the working queue if it's if it's in a holding period or in a holding place? That's a great question and one that I love to answer. And again, you've you've just you've just kind of found something that's my absolute favorite.

Of course, we get this question a lot. I know I do. Right. Absolutely. I mean, literally, I think that's the first question I ever get asked is and I think people very often get confused by the difference between a queue and a status.

So, you know, answering that question is the the ticket should stay in whatever queue it's in whilst it's in whatever status you've changed it to. So queues and statuses are independent of each other. They they shouldn't be called the same thing and they don't need to be called the same thing. So, you know, if you've got it using your or using the analogy of, you know, the working queue or the or the x-ray room, right, your analogy earlier on is, you know, once you've had your x-ray done, maybe that the x-ray technician is going to, you know, old school in hospitals, they might have a clipboard and they kind of tick to say, yeah, I've done the x-ray. So that's a status.

That's a tick box to go. X-ray has been done. Now the next stage is you might need to go and have plaster on your leg or you might need to go and, you know, have have a CAT scan or some other type of thing that you need to have. So as you're progressing through the stages in the hospital, you're you're getting a kind of a box ticked with a status of you as a patient, you know, as you're progressing through so that the next person who grabs you in line knows what's happened, but also knows, you know, what you're waiting for. So we're waiting for another x-ray to be done.

Are we waiting to to go into the room so we can have, you know, our leg bandaged up, whatever the case might be. And it's exactly the same in a service desk. You know, when somebody grabs a ticket and they start working on it, they're going to change that ticket into something like in progress and they're going to leave it in the support queue. What they're then going to do is they're going to say, OK, waiting for customer. Now, I don't need to have a separate queue called waiting customer.

I'm going to leave it in the support queue. So I'm going to leave it in the x-ray room, but I'm going to tick the box to say, OK, it's now waiting for customer because now I've got I've sent something to the customer and I'm waiting for them to come back or I'm waiting for some kind of approval or, you know, waiting for for parts from a vendor. But there's no there's no reason to move that ticket out of that queue because everyone is focusing on that queue. Remember, that's your working queue that everyone is looking at every single day and they need to know what the status of that ticket is and what effectively what's been done and what boxes have been ticked and what's still waiting to be done on it in the queue that they're focusing on all the time. Right.

So, you know, my concern about having the waiting queue is that nobody will be monitoring it and some things will get forgotten and lost. It's not going to be lost. It's going to be sitting in that waiting queue forever and ever until somebody comes in and actually does something with the ticket, moves the ticket, changes it back to a working queue. If it's in the working queue, whatever that working queue is, at least somebody is going to see it and you're going to see that due date turn red and you will be able to monitor, you know, the work on it. Like, hey, this thing is getting real, you know, stale sitting here.

It's been sitting here for two weeks and the status hasn't changed at all. Maybe somebody needs to follow up. Yes, we might be waiting for the customer, but the customer might have moved on to 20 other things since then and may have overlooked it. That's a follow up trigger. Like I have a workflow rule, you know, when I have a status on a ticket that's waiting customer, I have a notification that emails the customer every two days to let them know that I'm still waiting for them to get back to me on this or that, you know, or whatever it is.

And and that's just but that's statuses over here. Right. And like you said, the status or status depends on what side of the ocean you're on. Yeah. So and the status, you know, is really very independent of the queue.

If you start moving these tickets around from queue to queue to queue, eventually somebody is going to lose sight of it. And somebody who needs to work on it might not have access to the queue it's been moved to. You know, so it becomes very manual again, you know, trying to stay on top of who has access to which queue and do are they do they have access to the tickets where that they need to be working on. And that comes back to that that whole less is more thing, right, is the more queues you have, the more chances are the tickets get lost or or go missing or, you know, get forgotten about whatever the case might be, because people aren't looking at those queues or can't look at those queues because they don't have any access to them. So, you know, so I think the moral of the story here is keep your queues as simple as possible, have as few of them as possible.

And statuses should be, again, very simple. You should have something like a new, you know, in progress waiting customer, you know, and and potentially a complete or something to that effect, you know, and again, and I know we'll talk about statuses in another episode, but or statuses, as you guys would say. Actually, funny enough, I work with quite a lot of American customers. So I'm so used to saying status now. And just as an aside, I finally got used to your way of writing the date as well.

So well, we'll identify you real soon here. Absolutely. Absolutely. I'm going to have to I'm going to have to start spelling color without a U at some point. But no, I mean, you know, I think the the important thing is to have the statuses that are, you know, you don't you don't really need to have hundreds of different statuses either.

Like, you know, I've seen so many people with a status that is waiting customer, waiting materials, waiting parts, waiting vendor, waiting this, waiting that, waiting the next thing. I'm like, you don't need to have all of those waiting statuses. You just need it's just it's just another, you know, another decision that somebody is going to have to make. And they have to scroll through 70 different statuses in order to choose the one that is just right for the for the one that they're trying to that will take that will take valuable time out of that technician day to try to make all of these proper decisions. You know, and and when we get to the the issues and the subissue types, I'm going to have a very similar thought on that.

But try not to, you know, overcomplicate the decisions that your people need to make because it will you know, it'll solve a lot of problems. That's my sorry. Absolutely. And actually, well, so so that's probably the case, to be fair, for a lot of PSA tools. But, you know, specifically with all types, because they've got the ticket categories, even though I say don't have lots of statuses, you can actually limit the amount of statuses that are that an engineer sees on the ticket categories anyway.

So, you know, even if you had, you know, 50 different statuses on things, you can limit that, you know, per category. So like a password reset, you only see three statuses. So, you know, you could do that. The problem is, I find, though, when people are building those those ticket categories, if you've got 50 statuses, they don't know which ones to include in that ticket category or not. So if you just start from the beginning and actually keep it as simple as possible and don't, you know, put a status for every single little thing that you can possibly think of doing, you know, I always say to my customers, this isn't a competition.

You know, it's not a competition to see who can have the most statuses and the most queues. This is, you know, you've got to set up the system in a way that's going to make it efficient. And so that even when you start building things like ticket categories, which we'll talk about on another episode, but, you know, whoever is building those doesn't have to make the decision of, you know, do I include these five waiting statuses or do I include, you know, do I leave some of them out? If you only had one status that said waiting something, waiting customer, then the choice is made for them, because if they need a waiting status, that's the one they'll put into that ticket category. So, yeah, I mean, you know, so definitely, I think, I know we've spoken about a lot of different things and brought a lot of different things into here, but really, you know, I think the point we were trying to get across in this episode was really about, you know, you're always when you're setting up queues, think about the hospital analogy.

Think about, you know, the different rooms that you would have, the different doctors rooms. And if your doctors are doing completely different tasks and different roles, so you're level one and level two, then have two queues called level one and level two. But if all your doctors are kind of doing the same bit of work and you could have multiple people in the same room at the same time being diagnosed, then keep one queue as a support queue, for example. But always, you know, and I think no matter how big you are, whether you're a one man band or one person band or you're a 500 man company, you should always have a triage queue because you should always have that kind of catch all queue that captures all the other junk and only push the tickets that people actually need to focus on and actually need to work on into a working queue like support or sales or whatever queue you have and keep all the other junk or all the other stuff that you might not want everyone to just scroll through a whole list of tickets of what's in there. You keep those in a separate queue and then somebody makes the decision to put those into a working queue.

Yeah, I totally agree with that. What a fun conversation today. I always love these conversations with you, Ryan, because I think we're on very similar wavelengths and we think very similarly in terms of how we how we set the system up. So, yeah, and hopefully our listeners have got some benefit out of today's session. I think so.

I think we've put out some pretty good information and anybody who's trying to set up their auto task, the queues and the statuses are always right there for front and center. Everybody loves to jump straight to the service desk. And we already talked about, you know, why it's important to do all of the other things prior to the service desk. But, you know, when you do get to the service desk, you're thinking, oh, well, queues, I could probably make up 20 queues. Well, you don't need 20 queues, especially if you don't have 20 people.

Right. And there's no reason that each person needs his or her own queue. So keep it simple and and help standardize what you're doing in your business. And you're going to see it's going to make a huge difference. Absolutely.

Fully agree with you, Ryan. Yeah. What a fun topic to talk about. And and we could probably keep, you know, keep the recording going for hours on end. But, you know, we both have things to to get on with.

And I'm sure our listeners don't want to, you know, hear us waffling on and on. Yeah, exactly. So, yeah. So, you know, really, Ryan, all that's left for me to say right now is your PSA is the key to your MSP success. So go out and make an impact on your world today.

Thanks, Chris. See you next time. Thanks, Ryan. See you next time. Bye.

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.