[43] – Autotask: 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 I think this is the first episode in a few weeks where we haven't had a guest, 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 backend settings and we brought up queues and statuses and all those kind of things. So 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. 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. 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 one queue, a level two queue, and a level three queue, and they have very different jobs and very different tasks assigned there. So I generally have a help desk queue of some sort, like a level one, level two, 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 be entered in by 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, 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. 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 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 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? And my take on that is it's kind of, I always like to refer to it as some kind of holding area or some buckets or something.

So it's like 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 something very similar to a hospital. And you mentioned a triage queue earlier on.

So you guys over there have, I think you call it the ER or the emergency room over here. We call it A&E, which is accidents and emergency. But I think that the concept of them is pretty much the same. You walk in, there's a reception desk and you sit in a massive waiting room until your turn is called. And then 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.

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 different reasons. So 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, we can automate certain things within the ticket or a person, whether that be a dispatcher or whether it's somebody on the service delivery team is actually going to say, okay, this ticket needs to go to Rayanne, this ticket needs to go to Chris.

But they're going to put them 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 there. So again, using that same analogy, that would be like, okay, 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, okay, 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 the concept 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 and the service delivery. 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 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, okay, Chris is out for an x-ray right now. And then when the x-ray is completed, it might be handed off to the next task in line. And so therefore the status would be back into waiting on doctor, but we're still talking about healthcare here. So let's tie this in to a real live MSP service delivery and 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.

You've got the opportunity, you've got the quote, you send the quote out, customer says, this looks great. Now you go to 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. And 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 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 wizard.

So what are some other real live 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. To have a triage queue and that would be your holding queue.

I also always recommend that somebody has some kind of working queue and I call that a working queue as in 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. 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 the ER or an A&E. You're going to actually go to another room where they're going to work on you. Or the doctor is not going to come with his stethoscope and kind of listen to 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. So I would always say when a ticket comes in, make sure it always leaves that queue. Make sure the triage queue is only there 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... And I would almost always even say that potentially even things like monitoring alerts should actually go into that queue as well. The reason being is because a lot of that stuff is noise, right? So a lot of the stuff is going to go in the triage queue, it's going to heal itself, 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 got an alert generated, what's going to end up happening is your engineers are going to focus on that.

They're going to spend 15 minutes figuring out why the CPU is spiking, you know, and then the RMM is going to go and clear the alert and they've wasted all that time figuring it out. Or in some scenarios, and I've actually been in a scenario with an MSP where, you know, an alert has come in for a monitoring alert that's coming to the support queue and the support team spends 25 minutes talking about why it should or shouldn't be alerting at certain thresholds. And that's just wasting a lot of time, but it's because they're seeing the ticket in there and 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, 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 in to actually look at that ticket or, you know, move it to a sales queue or whatever the case might be.

But 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. I totally agree with everything that you just said. Think about 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. If everything goes into the triage queue, then you can set up your workflow rules and you can base it on things like issue types and priorities and set up standardized procedures for moving those tickets out, right?

So you were talking about the RMM and, you know, the monitoring alert that comes in. Well, 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 this monitoring alert has not yet self-healed. Maybe now is the time for somebody to take a look at it. So 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 in charge of looking at every ticket or, you know, 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 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 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. 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 the same, you know, different cues.

But 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 flag 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 and 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 high end engineers and you don't want them touching the help desk tickets 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. You have technicians or engineers with very, very different roles, and you don't want them ever crossing that magical double yellow line, then yes, split up the cues and get them out.

And keep them out of places where they don't belong. Keep the sales people out of, you know, the help desk cue by giving the sales people their own cue. That sort of thing. Is that pretty much what you're saying? Pretty much.

And that's, again, the reason why I think, you know, everything should come into a triage cue because there are going to be certain things that if you've got one cue for support and you've got level two guys, they don't need to be bogged down with or worried about tickets that a CPU is liking. So why put it into their cue, right? Put it into a triage cue and don't give anyone access to that cue except the people who need it. So except the people who are actually going to connect into that cue and are going to move the tickets around into different cues. And that's always why I say keep the tickets in a separate cue and keep your working cues 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 bogged down with what information is in there.

Then keep them out of those cues, as you say, and just let them see the information or the tickets in the cues that they need to have access to. So real life scenario, right? Ticket comes in, it's assigned to the help desk, somebody picks it up. And so they start working on the ticket and then they realize that they need to ask or they need to get some sort of permission from the customer in order to buy something. Now, do they change the cue, move it into a different waiting for customer cue?

Is it necessary to do that, to get it out of the working cue 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 just found something that's my absolute favorite thing to talk about. Of course. Well, we get this question a lot.

I know I do. Right? Absolutely. I mean, literally, I think that's the first question that I ever get asked is, and I think people very often get confused by the difference between a cue and a status. Answering that question is the ticket should stay in whatever cue it's in whilst it's in whatever status you've changed it to.

So cues and statuses are independent of each other. They shouldn't be called the same thing and they don't need to be called the same thing cue or the x-ray room, right? Your analogy earlier on is, once you've had your x-ray done, maybe the x-ray technician is going to old school in hospitals, they might have a clipboard and they kind of tick to say, yep, 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 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 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 what you're waiting for. So we're waiting for another x-ray to be done. We're waiting 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, but 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, I'm waiting for parts from a vendor. But 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. 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, you know, 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 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. I have a workflow rule 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, whatever it is. And that's just, that's statuses over here. Right.

And like you said, the status or status depends on what side of the ocean you're on. So 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. So it becomes very manual again, trying to stay on top of who has access to which queue and do they have access to the tickets that they need to be working on.

And that comes back to that whole less is more thing, right? Is the more queues you have, the more chances are the tickets get lost or go missing or 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. 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 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 guys way of writing the date as well. So.

Well, we'll yankify 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. I think the the important thing is to have the statuses that are, you don't really need to have hundreds of different statuses either.

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 to. It's just another another decision that somebody is going to have to make. They have to scroll through 70 different statuses in order to choose the one that is just right for the one that they're trying to.

That will take valuable time out of that technician day to try to make all of these proper decisions. And when we get to the issues and the sub issue types, I'm going to have a very similar thought on that. But try not to overcomplicate the decisions that your people need to make because it will, you know, it'll solve a lot of problems. 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 50 different statuses on things, you can limit that, you know, per category. So like a password reset, you only see three statuses. You know, you could do that. The problem is, I find, though, when people are building 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 so that even when you start building things like ticket categories, which we'll talk about on another episode, you know, whoever is building those doesn't have to make the decision of do I include these five waiting statuses or do I include, 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 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'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 doctor's 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 peak one queue is 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 catches 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. Yeah, it's been a lot of good fun.

It's been good fun getting back and just having a chat with just yourself and me. And I always love these conversations with you, Ryanne, because I think we're on very similar wavelengths and we think very similarly in terms of how we set the system up. So 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 autotask, the queues and the statuses are always right there front and center.

Everybody loves to jump straight to the service desk and we already talked about 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 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, Ryanne. Yeah, what a fun topic to talk about. And we could probably keep the recording going for hours on end.

But, you know, we both have things to get on with. And I'm sure our listeners don't want to hear us waffling on. Ramble on. Yeah, exactly. Yeah.

So, you know, really, Ryanne, 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, Ryanne.

See you next time. 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.