To grow, MSPs must intervene on 10 Types of Tickets
Overwhelmed by a sea of tickets at your MSP? Wondering how you can you tell from a list of hundreds of open tickets which ones merit your attention? And even more importantly, how to prioritize which ones need attention first?
You’re not alone.
I know you want to move the needle in your journey to being a Best-in-Class MSP…but sometimes, it can feel impossible to get unstuck, right? The good news is there are only 10 Types of Tickets that an MSP needs to monitor and take action on to drive Service Delivery Improvements. The bad news is it’s not easy, and if each list of tickets is out-of-control, the MSP may need outside help to drive Service Delivery Improvements.
So, let’s jump right in…
Top 10 tickets every MSP needs to know about
Based on best practices of MSPs from around the world, we’ve compiled 10 lists of tickets that every Service Coordinator, Service Desk Manager, Team Lead, Service Manager and owner need to monitor. To bring order to this chaos, we recommend a dashboard with eight widgets, two Autotask Live Reports, implement the recommended SOPs, hold the Team accountable, and then life gets easy – we guarantee it.
The list includes:
#1 New Tickets:
#2 Coming up on Next SLA Due Date:
#3 Waiting … with last Activity date greater than 2 days ago
#4 On Hold with past Due Date
#5 Tickets without Service Calls requiring scheduling
#6 Worked Hours greater than the Estimated Hours
#7 Maintaining the Ready to Engage widgets
#8 Scheduled Tickets with No Future Service Calls
#9 Backlog List of Tickets (BLT) greater than 5 per Tech
#10 All Open Tickets greater than 20 per Tech
Great, we now have a prioritized list. Why is the list prioritized this way, how do we find the tickets in the lists, and what do we do with them?
#1 Widget: New Tickets:
New tickets are always the highest priority. From our experience, if an MSP invests in developing a great intake SOP, the majority of Service Delivery issues go away. It makes sense that working on Service Delivery Improvements from the beginning to the end of the clients' Service Request journey is the best path to resolving Service Delivery issues. Of surprise to us is that doubling down and fixing the intake process results in most of the Service Delivery improvements happening organically. So, not only should new tickets be the highest priority, but having a great SOP and the right person doing ticket triage is also critical.
With this in-mind, we recommend a widget in the upper left-hand corner of the Autotask dashboard showing new tickets. The filtering is pretty simple: Status is one of "New" and "Return to Triage." And the goal is to have an empty widget.
For what to do with the list of tickets, here is an article on “How to Triage Tickets”: Click Here to read the article
#2 Widget: SLA Summary:
The second most important set of tickets needing attention are the ones approaching Next SLA Event Due Date. The #1 widget (New Tickets) has resolved the challenge of meeting the 1st Response SLA. What’s left is knowing which tickets are nearing Tech Engagement Due or Completion Due.
For those tickets meriting attention, we can consider the following:
Is there another tech with the right skillset available to take the ticket? Check the Tech Workload Balancing dashboard.
Does the manager have any bright ideas or know of someone who is readily available – without disrupting the techs?
Notify the client that the team is running a little bit behind, the client's request hasn’t been forgotten and will be addressed ASAP.
This is a standard widget from the Autotask library. The goal is for this widget to be at or near zero at all times.
For what to do with the list of tickets, here is an article on SLA Performance: Click here to read the article
#3 Widget: Waiting …
Even a non-technical person can pick up the phone and call the client, vendor, or distributor. In the case of the client, 80% of the times I called, they denied knowing we were waiting on them. No worries…here’s the info we need: (….). Once I have this info, I can get your request back on-track.
On more than one occasion, I needed to call a vendor and explain that our tech needs to talk with one of their techs. Can we please schedule a call?
Waiting Parts should never take more than a day, let alone two days. Within minutes of ordering the parts, we had an ETA. Once we had an ETA, we scheduled the Tech to engage on the Client's request 48 hours after the parts were Estimated To Arrive.
No tickets should be waiting more than two days. Based on our experience, techs take the attitude that they’ve notified the client, vendor/distributor, and it’s now the client, vendor’s/distributor’s responsibility to respond. Life would be great if it worked that way, but unfortunately, more is needed to provide superior service to the client and convert them to raving fans. The MSP needs to be accountable for keeping things moving and have someone empowered to drive the request from cradle-to-grave.
The filtering for this one is also simple: Status is one of Waiting Client, Waiting Vendor, Waiting Parts. It’s sorted by Last Activity Date. The goal is to have no tickets with a Last Activity Date greater than 2 days.
For what to do with the list of tickets, here is an article on “KPI’s”: Click here to read article
#4 Widget: On-Hold
The On-Hold widget is a stop-gap to make sure tickets like this aren’t lost. The on-hold mechanism removes the ticket from the Tech's Ready to Engage list of tickets until its due date is reached. At this point, the ticket is returned to the tech and added to the Ready to Engage list based on an updated SLA calculation. If the due date of an On-Hold ticket is in the past, it’ll never be returned to the Tech’s Ready to Engage widget, and therefore runs the risk of being dropped.
Once again, the filtering is nice and simple:
Status = On-Hold
Due Date < Today
The goal? To have an empty widget.
For what to do with the list of tickets, here is an article on Work Flow Rules: Click here to read the article
#5 Widget: Tickets requiring scheduling:
The finesse of when to schedule and when to add it to a Ready to Engage worklist is elusive, but it doesn’t need to be. Yes, tickets with a Dispatched Remote or Dispatched On-Site status need to be scheduled with a Service Call attached to the ticket. But there are other types of client requests requiring scheduling. All projects need to be scheduled in order to even have a chance of completing the project on-time and on-budget. As a matter of fact, any Installation or M/A/Cs > 4 hours of work (Move/Add/Changes) need to be scheduled. Put simply, any work estimated to be greater than 4 hours needs to be scheduled by the Service Coordinator.
A few other types of client requests need to be scheduled, but it’s harder to capture them with a widget filter. For example, UPS battery replacement starts out as a failed UPS alert. It typically requires tech engagement to determine that the batteries need to be replaced.
As you can imagine, the filtering for this widget is a bit more complicated. But it starts with Service Call Scheduled not equal “Yes”. You also need Workflow (Priority) set to Projects, Installations, MACs > 4 hours.
Autotask does not have "OR" statements in widget filtering, so it’s better to go with a widget that shows count of tickets, rather than a list of the tickets themselves. This way, you can have a sub-widget for tickets with:
#5A: Workflow (Priority) is either Project, Installation, MACs > 4 hours.
#5B: Status is either Dispatched Remote or Dispatched On-Site
#5C: Estimated Hours > 4 hours
The key is to remember that all three sub-widgets also need the filter Service Call Scheduled Not Equal “Yes”.
For what to do with the list of tickets, here is an article on Dashboards: Click here to read the article
#6 Widget: Worked Hours > Estimated Hours
FYI: based on your historical performance, there is a way to automate populating the Estimated Hours field in a ticket. Automating this field is critical to identifying one type of ticket that needs Intervention – the ones taking way longer to complete than they should.
The widget filtering is, once again, pretty simple… Variance Hours less than 0. I would also sort on Variance Hours from Least to Greatest, so the tickets with Total Hours much greater than Estimated Hours floats to the top of the list.
For what to do with the list of tickets, here is an article on Monitoring Alerts: Click here to read the article
#7 Dashboard: Tech’s Ready to Engage widgets
Now, this is not a widget, but a dashboard of widgets showing what is in each Tech’s Ready to Engage widget. The most important widget for the techs is one the list of tickets they can engage on "at-will." Techs also have a habit of not maintaining their dashboards, widgets, documentation, time entries, etc. They’re great at fixing the client's stuff but not so much with communications or documentation. To have a smooth-running ship, you need to wrap these great billable resources with a support team that takes care of their stuff – meaning their dashboards.
From our experience, if the Ready to Engage widget is not in fine working order, the techs won't use the dashboards and will revert to their queue views - with all the On-Hold and Waiting tickets mixed in. They tend to focus on the squeaky wheel clients while ignoring tickets with earlier due dates. This recipe for chaos is definitely not something any quality MSP wants their service delivery team cooking up.
Having a non-billable person maintaining the Ready to Engage widgets, by making sure the Next SLA Event Due Date is in the future, goes a long way toward having the techs know what to work on next.
But none of these supporting widgets are as important as maintaining the Ready to Engage widgets in fine working order. If a ticket has no Next SLA Event Due Date, or if the date is in the past, there are three things that can be done to fix the problem:
If no Next SLA Event Due Date exists, it’s most likely a reopen ticket, and the ticket history will need to be edited, wiping out the SLA Resolve Date, for the SLA to recalculate a new Next SLA Event Due Date and properly ordering the ticket in the widget.
The ticket can be scheduled for some future time with ample time allocated to complete the work.
If it looks like the work has been completed, ask the tech to add documentation and time entry and then close the ticket.
For what to do with the list of tickets, here is an article on Dashboards: Click here to read the article
Now we transition from Widgets to Reports as there are two other lists of tickets that need Intervention that are not contained in a widget.
#8 Live Report: Scheduled Tickets with No Future Service Calls:
Techs have been known to complete a scheduled engagement to a client’s satisfaction, only to not finalize the effort by marking the ticket Complete. Their heart is in the right place – “I will stick the ticket in my back pocket and get to it ASAP.” The problem is getting back to it never happens. A year later, Carol comes along asking, “Why is this ticket still open??”
Now, to save you from this embarrassment, we highly recommend an Autotask Live Report that looks at all open tickets that have a service call with no Service Calls in the future. Writing the report is tricky in that pulling the last Service Call record to the ticket group footer provides the date of the last Service Call attached to the ticket. If the date is in the future, suppress the Group Footer, and the ticket disappears from the list.
Voilà, you now have a list of scheduled tickets with no future service calls. Scooping up this list and asking the tech how much more time they need (if the answer is 0, then simply ask them to add the documentation, time entry and close the ticket), and then rescheduling the remaining ticket ensures they’re moving forward and prevents them from being found a year later by Carol.
For what to do with the list of tickets, here is an article on Dashboards: Click here to read the article
#9 Live Report: Backlog List of Tickets (BLT)
A backlog list of tickets is different than the number of Overdue Tickets. Overdue Tickets are based on the due date in the ticket, which can be changed and then you have no more overdue tickets. The risk in this approach is having a disappointed client waiting for resolution because you're fulfilling your mission of providing superior client service.
From the client's perspective, if the request is Break/Fix, they expect it fixed within a week (often sooner). If the request is for an Installation or MAC, they tend to be a little more relaxed and can expect it to be completed within a month.
Setting up a Backlog List of Tickets with widgets is possible, but it takes two widgets. In this case, widgets are not as useful as a Live Report, which allows you to schedule a report to come out on a Wednesday morning and to schedule time on the following Thursday afternoon to work the list.
What happens between Wednesday morning and Thursday afternoon is magic. The first thing a tech will do is look at the list of tickets in their name. They’ll often just add documentation and time entries and close the ticket before anyone else notices. If they need help either from a mentor, higher-skilled Tech, or Google, they’ll usually find time to do the research before Thursday afternoon. Then when Thursday afternoon rolls around, more tickets are completed per hour than any other day or time of the week. This can be guaranteed by calling for a digital blackout to remove external distractions, except the one tech assigned to critical responses for that day.
For what to do with the list of tickets, here is an article on Backlog Tickets: Click here to read the article
#10 Widget: All Open Tickets
Before walking away, we'd be remiss if we didn’t say someone should always know how many open tickets there are. Of course, looking at the list doesn’t indicate which ones need intervention, but the volume of open tickets compared to the number of techs (20 per tech, for example) is an indication if overall intervention is needed. If the list is too large or growing, proactive mitigation steps are needed.
In a day and age when COVID reigns, having this information has never been more critical. If suddenly two techs are out-of-office for 14 days of quarantine – what was OK (120 tickets for a 6 Tech shop) becomes a crisis (120 tickets for a 4 Tech shop is not OK).
What are the mitigation steps for the MSP?
I was in this situation on more than one occasion. I would calmly let everyone at the MSP know the situation and explain that with two techs out and more than 20 tickets per tech, not everything was going to get done as expected. I would then set a priority order as follows:
Critical tickets would be going to the designated critical response tech
All other incidents (High, High-Backup, Medium and Standard) would be handled within SLA
All M/A/Cs would be handled as best as we could, with most handled within SLA
All onsite work, Installations, and Projects would be scheduled after all the other work was reviewed and assigned and would most likely miss SLA.
For the record, the communication didn’t go over well. My supervisor called me to the principal’s office (I was very familiar with the path to the office) and was told in no uncertain terms that everything had to be done as expected – within SLA and that nothing could be made to wait. My response was that it was illogical and impossible, but we would do our best based on the priority order given. I was still there years later, bringing order to chaos as any good Service Delivery Gladiator would do.
Whew! This was certainly a lot to go over. I know many MSP owners and service managers are just looking to “fix a few things” and all of this seems overwhelming.
Trust me, if you really want to move the needle on the journey towards being a best-in-class MSP, then you need to follow these 10 steps. But you don’t have to go it alone: Advanced Global can help you stop the nightmares and navigate that massive sea of tickets way faster than you can on your own. Our proven implementation process teaches you how to do this, ensures everything is done right and will stand the test of time, and holds your hand like a true partner every step of the way.
We start by offering a FREE No-Obligation PSA Configuration Evaluation
The Elephant in the room:
Who is Advanced Global, and why should we listen to them?
Recently someone we’ve been in communication with since DattoCon 2018, who was faithfully reading our articles, commented that up until a few months ago, “I really did not know what Advanced Global does.” So here are a few bullet points to let anyone interested know who we are and what we do:
We Are – the Autotask Global Service Delivery Authority
We Help – MSPs thrive
We Solve – Service Delivery issues, inefficiencies, and challenges by making sure:
techs know what to work on next
someone is managing all open tickets and driving them to completion
the staffing levels are correct, and the workload is balanced
Real-Time Time Entry is a cultural habit
the Client has a great client experience
profit is maximized
Autotask is being fully leveraged the historical data that is in the Autotask software is accessible to benchmark, track & USE effectively
the Service Delivery operations can scale
projects are completed On-Time and On-Budget
the company can grow
MSPs know what they don’t know
Our Tools:
Autotask “Best in Class” standard build
Our MSP robust Service Delivery SOP library
Advanced Live Reports
Expertise in providing a transformational experience
Note: We are not philosophers; we are doers with 31+ years of Service Delivery experience, bringing real Service Delivery Improvement change, profitability, and Best in Class performance.
We start by offering a FREE No-Obligation PSA Configuration Evaluation