“You can run, but you can’t hide” is phrase we apply to a lot of things in business and life, but for MSPs, it most appropriately applies to tickets and time.
You’ve probably heard me call ticket time the “invisible force,“ mainly because many MSPs don’t have a good command over the metric.
The average MSP wastes all their resources on tickets or projects. For MSPs, this oftentimes creates a host of issues, especially regarding value, margin and scalability.
We at TruMethodshave come up with several concepts to help you quantify your noise levels relative to the seats you have under management.
We started with tickets per month per user, and then we added RHEM, which includes reactive time. The issue we found was tracking time on tickets is very difficult — and most of the time: The math didn’t add up correctly.
Most recently, we’ve been encouraging members to look at the ratio of support resources to seats to see how many seats a resource can manage. While this makes it easier to calculate, the issue is this: If you’re a noisy MSP, you’ll have tickets on everyone’s service board, so things get escalated. They’re on all the boards and queues, so determining how many resources work tickets can be a little fuzzy.
In general, if you can get it right, you want one support resource to manage at least 500 seats, so here are my recommendations to you.
First, work hard to quarantine the noise.
Have all tickets and alerts go to one border queue. This way you can more accurately manage and report on the volume. (In other words, you can quantify the issue.)
Next, look for some low-hanging fruit to lower reactive time (examples are escalations). Look at each ticket that needs to be escalated off the support board and find out why. This is especially true for any on-site escalations. On-site reactive escalations are poison to an MSP and need to be virtually eliminated. Then, look at tickets you spend more than 35 minutes or so on, and find out why.
Third, you and your team need to take a TNT (today, not tomorrow) attitude. Your goal is to resolve all of today’s tickets today, so you’ll have enough time to do tomorrow’s tickets tomorrow. One quick check as to how you’re doing with this is to look at the average number of tickets and alerts generated on average in a day and compare that to the number of tickets still open at the end of the day.
For example, if you do 25 tickets a day and there are 75 tickets open, you have an issue. (That’s three days‘ worth of tickets.) Even if no tickets came in, it would take you three days to catch up. Uh, Houston, we have a problem.
Have each support resource report the number of tickets closed each day in their morning huddle. Tickets closed for tech needs to be a key metric that people are accountable for. If they can’t reach the metric, ensure tell you why.
Finally, look at your policy for new workstations and laptop installs. This is a giant black hole for many MSPs. Do you include them in your seat price? If so, this is reactive time. This can be significant. You may charge a flat fee for them. You may bill hourly. But you need to look at this because if you’re including new workstations, in your monthly fee, this is a huge potential issue because most MSPs have not accurately accounted for the cost in their seat costs, so that’s one big place you can take a look.
If everyone is doing tickets or projects that can’t happen, all team members need to be on the same page in terms of how you manage report impact ticket counts.
You can run from reactive time, but you can’t hide it