MSP Service Metrics You Need
Managing an IT service delivery team can be an incredibly challenging job. There often seems to be an endless stream of requests, with finite resources to apply to the requests. When you’re small you can try to keep tabs on all the tickets that flow in but as you grow, this approach becomes impractical. Instead of trying to keep an eye on everything you need to move to manage by the numbers.
SLA
The first numbers you should start to manage are the service level agreement (SLA) compliance. An important part of using an SLA for service management is that you don’t need to publicly state your SLA goals. It’s often best to start using SLA simply as an internal measure of your service.
Average time to acknowledgment
The first point of contact in any communication is critical. Therefore it makes sense that how long it takes for you to respond to a user request for support is one of the most important metrics. Let’s be clear, your systems auto-responder that acknowledges that you have received the email they sent does NOT qualify as an acknowledgment.
Acknowledgment is when a human responds to a user via phone or email to set expectations for service.
Communication is a severely underleveraged tool in IT service delivery. In many cases, you can buy yourself hours or days with a user by setting an expectation of service. If a user is contacted within 30 minutes of submitting a ticket and told that someone will contact them before the end of the day, in 90% of cases they are fine with that.
The alternative is that a user submits a support request and doesn’t hear from someone before the end of the day. The user spends the whole day wondering if anyone is even going to help them. They waste time trying to fix it themselves, they may email several more times and then phone to clarify if anyone is able to help them fix it.
There is no difference between the time to service in both of these scenarios, but the difference in communication makes a dramatic difference in the user’s comfort with what to expect. This is why the time to acknowledge is so crucial. You can actually buy yourself a lot of time simply by communicating effectively and setting expectations with the client.
The industry benchmarks for time to acknowledge are 15-30 mins is best in class. 1-2 hours is typical. Anything beyond 4 hours is problematic.
Average Time to Resolution
Ultimately when a user is requesting support from the helpdesk, they want their issue to be resolved as quickly as possible. The time from when the ticket is opened to when the ticket is closed is the elapsed time of the ticket, the time your team spends actually working on the ticket is the elapsed SLA time. Most PSAs track your SLA performance based on the time spent working on the ticket, not the time elapsed since the ticket was opened. The elapsed time is not unimportant, but it’s a tricky one to commit to since there are so many variables beyond your control that can interfere with that number. For instance, if you call a user back and they ask you to help them with an issue 2 days from now because they are busy and their issue is low priority, you don’t want your resolution time to get dragged out 2 days.
Instead, your SLA resolution time is measured by the time you spent working on the ticket itself.
The industry benchmarks for time to resolution are 30 - 60 minutes, less would be best in class. 1-2 hrs is typical. Anything beyond 4 hours on average is problematic.
Customer Satisfaction (CSAT)
CSAT is a crucial metric to monitor. Broadly this metric is like a barometer for how the client users view your service delivery. You may think you’re doing a great job, but if the users don’t agree you’re in trouble.
You need to use a one-click CSAT system. If you’re using a standard link-based survey for client feedback your rate of feedback is likely to be very low. Less than 5% of tickets will get feedback. A single-click CSAT system will give you a much higher rate of feedback due to its ease of use. One-click systems can see 15-40% of tickets rated, depending on how much you train the users to provide feedback. I have several other blog posts that talk about the importance of CSAT.
(How Customer CSAT creates better customer experience)
(How measuring CSAT impacts your business).
You should be targeting for greater than 85% positive feedback. Industry best in class is over 95% positive feedback. Again, approaching this metric at a global level, as well as a client-by-client basis will provide a huge benefit.
If you’re not using negative surveys as a trigger to reach out to the user, you should. This is a powerful practice that demonstrates to the user that you are listening to them. It will generate an incredible amount of goodwill and encourage users to provide more feedback.
Kill Rate Percentage
Kill rate is a measure of how many tickets you close compared to how many tickets are opened in a period, typically per day. Kill rate is an important internal measure to ensure your team is able to manage the volume of incoming tickets. If you aren’t closing as many tickets as are being opened, you end up with a backlog. A ticket backlog will crush your performance numbers, but also causes significant psychological weight to the team. They can see the number of open tickets growing and they know they aren’t staying on top of the workload.
Counterintuitively the best approach to increasing your kill rate percentage isn’t always “doing more.” If there is a productivity issue within the team then doing more may be appropriate. An easier approach is often doing less! I know right!? How can you get more done by doing less? Many IT companies suffer from bloated processes and low-value busy work. There are often processes that once served a purpose, but are no longer valuable. I challenge you to do an in-depth analysis of the workload of the service team. It is likely that 10-20% of the work being done isn’t serving you or the customer.
Once you’ve reviewed and leaned out the work being served up to the team, you can now focus on the raw productivity. As a benchmark reference Tier 1s should be completing 10-20 tickets per day, tier 2 techs should be closing 5-10 tickets a day, and tier 3s should be closing around 5. This is a broad reference range and you’ll need to baseline your own techs to determine where improvements could be made.
Average Tickets Per Seat
The number of tickets generated per managed endpoint or per user is a great measure to determine where the noise in your service desk is coming from. This metric also helps determine if a client is consuming the appropriate amount of resources from your team.
Best-in-class performers will see 0.5 tickets per managed endpoint. Typically this number is 1.5 tickets per seat. You should target 1 ticket per seat per month. This is a very attainable goal in most cases. It’s likely that you’ll see some clients with more than 4 tickets per seat. These clients should be put under the microscope to determine why they are so noisy. The most common cause to look for is a non-standardized environment. The less uniform the client environments are and the more they drift from your defined tech stack, the noisier they are likely to be. There are also usually noisy users who require some training.
Focus on driving down tickets per seat on a global level, as well as on a client by client level. This two-fold approach will go a long way to reducing the volume of work. Plus your users will be happier because they won’t have to reach out to IT as much for support, which means they are also more productive.
Aged Tickets
The SLA measurement of a ticket is not the same thing as the total age of the ticket. Therefore it’s important to also look for aging tickets. As a service manager, you want to ensure that tickets are moving through the service desk in a fluid fashion. There shouldn’t be a lot of tickets that are more than 30 days old. Ideally, tickets are never more than 7 days old, but this also isn’t typical. Setting a target of the number of tickets over 30 days old is a great way to create a review process for those tickets. Review the tickets over 30 days each week. If you have a serious backlog, like hundreds of tickets, it may not be practical to review them all. In this case, be a bit ruthless with the old tickets. In most cases, the tickets can be closed. I routinely see service tickets that are over 200 days old. Put some pressure on the tech responsible for that ticket, what is required to close that ticket, is it even still an issue? Has the issue been qualified with the user to see if it’s even still an issue? Keeping tickets from getting too old will help ensure a more lean approach to ticket management. You shouldn’t be randomly closing old tickets, but you should be less tolerant of keeping old tickets around.
Stale Tickets
Stale tickets refer to tickets that have not been updated for a period of time. This is usually three or four days. Establishing an expectation that techs keep their tickets updated every 3-4 days helps to ensure they are more accountable to driving them to some resolution. In order for this to be practical, techs should not have more than 20 support tickets assigned to them at a time. Project tickets are an exception and don’t count towards this number. If a tech has more than 20 tickets it becomes difficult for the tech to keep the tickets afloat.
Ensuring tickets don’t become stale and untouched for weeks on end provides a system that increases communication with the user. For example, the tech may be waiting for a vendor to get back to them. That doesn’t mean they get to just abandon the ticket until they hear back from the vendor. They should be using the ticket to follow up with the vendor and communicate activity and next actions with the end-user. Some see this as an onerous expectation, but it works really well to ensure the tech is motivated to drive that ticket to a speedy resolution. It also creates a higher quality experience for the end-user by keeping them informed about the activity being performed to solve their issue.
There are few things people hate more than the unknown. If they go weeks without hearing an update on their ticket, they are rightfully annoyed. Managing stale tickets helps to avoid this service trap.
Expensive Tickets
One of the strongest levers an MSP has to increase profitability is reducing the cost of support for each ticket. The more time spent on a ticket, the more expensive it becomes. Industry best in class is about 30 minutes per ticket or less. Any ticket reactive support ticket that has more than 4 hours of time on it is potentially an out-of-scope request or a more gnarly problem that requires more management. Tickets with more than 4 hours of support should be reviewed on a weekly basis and there should be a clear understanding of what is required to drive those tickets to resolution. Does the ticket require escalation? Should it have been scoped as a project? Does the tech have what they need in order to resolve the ticket before it balloons in cost?
If you are able to catch these tickets earlier with other metrics or processes, that’s great, but once they balloon to more than 4 hours you need to become diligent about steering those tickets towards resolution.
The power of numbers
Service management is a complex responsibility. There are a ton of competing interests and a dizzying number of data points that must be managed constantly. As the service delivery team grows, it becomes increasingly impractical to manage by simply having a hand in everything. Moving to a KPI-based management system allows for the service manager to spot trends and manage based on exceptions.
Know your KPIs, define your baseline expectations, and step in to assist when those KPIs begin to drift outside the range of what’s acceptable to attain your goals. This is a more scalable way to keep tabs on service delivery without becoming overwhelmed.
