Backlog Tickets, the nemesis of an MSP
"We have met the enemy, and he is us" (Pogo Comic Strip, 1970). The goal of every MSP is to have raving fans. They’re the hallmark of a job well-done, and their referrals are a more efficient and effective way to grow a business than any other Marketing/Sales strategy.
I think we’d all agree that an MSP needs great Service Delivery to get those raving fans. So why do we allow the enemy of raving fans, the Backlog Ticket list, to exist? Why can’t we catch up? And when we do catch up, the next burst of activity ultimately sets us right back where we were. To make matters worse, how can we tell a prospective client we are their best option when it comes to MSP support, when we are the only ones with a Backlog Ticket List (FYI: this is a false premise and head trash: 94% of MSPs have Non-Project tickets more than 14 days old).
To solve the problem, we must know our enemy. Our #1 set of Key Performance Indicators (KPI) come from the Autotask dashboard we stare at every day. The dashboards are #1 because they’re easy to build and constantly and instantly report tangible, relevant information. They’re also #1 because if you know how to read them, they can point you to where the Service Delivery team is not meeting expectations and where a Service Manager should focus efforts for continuous improvement.
If you need an Automated Autotask Backlog Ticket List Live Report – contact us at info@AGMSPCoaching.com)
In the case of Backlog Tickets, the dashboard indicator is Overdue Tickets. But this is not to say that Overdue Tickets equate to Backlog Tickets or vice versa. Overdue tickets are driven by the due date in the ticket, which can be manually changed to a month from now and voila, no overdue tickets. However, the client experience can be disappointing and could result in something much less than a raving fan. Even if all Non-Project Tickets are within SLA management, it’s easy to put the Overdue Tickets on Hold or Waiting for something, and throw the Due Date out to the end of next year.
The Four Levels of Damage caused by Ticket Backlogs
So why worry about Backlog Tickets if we can just hide them from the dashboard? The damage caused by Backlog Tickets happens on four levels:
Poor customer experience, damaging the relationship and preventing raving fans
Not meeting contractual obligations. While we've heard of very few legal battles over not meeting the SLAs in the agreements, we know this can cause churn and recently talked with one MSP who recounted a meeting with a large client that had a copy of their SLAs in hand and a list of SLA breached tickets – that was a very uncomfortable meeting, indeed!
Keeping Techs from focusing on working tickets based on the Next SLA Event Due Date because of their tendency to choose to work on new requests over last week's request.
Preventing the MSP from maximizing efficiency – not only are the Techs more inefficient in eventually closing out a backlog ticket, but the overhead it takes to manage a backlog is significant. Just think about the number of times we apologize to the customer or the number of times a Service Coordinator needs to pick up a backlog ticket only to put it back down again. Or even your time reading an article about what to do about Backlog Tickets!
If backlog tickets don’t equate to overdue tickets, then what are they? According to MSP industry legend Gary Pica, any non-project ticket more than 30 days old is a backlog ticket. In his view the Customer won’t pay for these backlog tickets even when completed. Our take is that this is true for Service Requests, but Incidents, Break Fix, and Reactive Work seem to hover around 7 days. Therefore, our Backlog Ticket list contains all incident tickets over 7 days old and all non-project service request tickets over 30 days old.
It’s easy to create a list. A ticket search of all Incident tickets over 7 days old can be run and exported from Autotask. Then run a ticket search of all non-project Service Requests over 30 days old and combine the two reports. In the Advanced Global world, Incident tickets have either a Critical, High, High-Backup, Medium, Standard, or Quick Hit priority (we use the underutilized Priority field to indicate which Workflow a specific customer request [Ticket] is in), and Service Requests are ones with Moves/Adds/Changes < 4 hours, M/A/C > 4 hours, and Installs (IMACs).
Assembling a Backlog Ticket list this way is a manual process, which is the biggest contributor to why we don't do anything productive about the list. Fortunately, we can help to automate the list creation process. Please contact us at info@AGMSPCoaching.com.
Why Backlog Tickets Lists are our Nemesis
This brings us to why the Backlog Ticket list is our nemesis:
We’re numb to the negative impacts of the list
We’ve gotten used to having the list
We believe a list of Overdue tickets is a fact of life
We believe there is nothing we can do about it.
We don’t hold ourselves accountable - OUCH.
I once had a supervisor whose philosophy was that if the request was more than two weeks old (he wasn't limiting it to customer requests) and I hadn’t gotten to it, I should delete it. If it was something that someone still wanted me to do, they’d just ask me again. I immediately went to the lead Project Manager and asked her if that was true (I could just delete all her emails, and if it were something she still needed, she would just ask again). She flew into a rage and told me in no uncertain terms that her requests were important, and they should be at the top of my list. So much for just deleting any Backlog Ticket over 30 days old. I'm sure our customers feel the same way the Project Manager did, whether Gary agrees or not.
The Solution: How to Resolve your Ticket Backlog Problem
So, what’s the solution? We recommend anytime the list of Overdue Tickets or list of Backlog Tickets reaches more than five per Tech, the Service Manager needs to get involved and lead the charge. If each Tech has five or fewer Overdue tickets, they should be able to get caught back up; over five, they just never seem to get to them.
Once the Service Coordinator alerts the Service Manager that there are more than 5 Backlog Tickets, the Service Manager will need to pull the Team together, inform them of the situation, remind them the expectation is ZERO backlog tickets and all tickets are engaged on within SLA, and lays out a strategy to remediate the situation. (PS: the same supervisor mentioned earlier also asked in an "All Staff" meeting, "When did we start going home before all the tickets were closed?")
There are several strategies for a Service Delivery Team to collaborate and reduce the Ticket Backlog List. However, there are only two that we recommend:
Wednesday afternoon Backlog List killing party
Digital Blackout.
Wednesday afternoon Backlog List killing party
The beauty of this strategy is that it starts on Tuesday morning by having the Backlog List of Tickets automatically generated and sent to everyone on the Service Delivery Team. From our experience, sometime Tuesday morning the Techs will look over the list to see which ones they can add their time to and close (often with very thin documentation and poor communication to the Customer), and which ones require some mentoring from other Techs.
For the mentoring help, they’ll most likely give the other Tech a heads up that tomorrow afternoon in the Backlog Ticket List Killing Party they’ll need to have a conversation around a ticket . That evening the mentoring Tech will take a moment to look at the ticket and figure out what’s going on.
Overnight, the ticket is on both Techs' minds, and at 1 pm on Wednesday there’s a brief, well thought-out conversation, and the ticket is closed 15-45 minutes later.
The Wednesday afternoon Backlog Ticket killing party is an all-hands effort, except for the one Tech designated to cover Critical Requests during this time period. No project work and no onsite visits. These need to be scheduled outside of the Ticket Killing party. Even the Service Coordinator is called to action following up on all the Waiting Tickets. And the Service Manager’s#1 responsibility is to hold everyone accountable – no excuses.
Digital Blackout
There are scores of articles about how our Digital Addictions are trashing productivity. Recently, one of the Datto development teams enacted a Digital Blackout between 1 pm and 3:30 pm. As a result, they were able to reduce their development cycle from eight weeks down to 2=two. In other words, they were four times more efficient with a digital blackout than in the normal course of business.
We recommend that all Techs (except the one pre-scheduled to take Critical Requests) go into a Digital Blackout from 10 am to 11:30 am. This 90-minute period has no reading of emails, cellphone turned off, no instant messaging (MS Teams, Slack, etc.) and no website surfing. This strategy is best used to keep the Backlog Ticket List from occurring in the first place, but it can also be used to reduce the list. Maybe the two go hand in hand? If the Tech is working on their list of tickets based on the Next SLA Event Due Date, then the tickets on the Backlog Ticket List would go first, followed by the ones that still have a chance of meeting Customers' expectations.
The bottom line is that we cannot allow Backlog Tickets to take root if we want our Clients to be raving fans. Once these tickets clog up our ticketing system, they are extremely hard to close in a timely matter and a Ticket Killing Party is needed. Best to stay on top of them by having a Digital Blackout and holding everyone accountable for keeping the Backlog down. Only then can we truly utter the original words of Oliver Hazard Perry that Pogo parodied, “We have met the enemy and they are ours.”
If you need an Automated Autotask Backlog Ticket List Live Report – contact us at info@AGMSPCoaching.com)
- Steve and Co