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 system's auto-responder that acknowledges receipt of the email does NOT qualify as 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 anyone 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, 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.
Industry benchmarks for time to acknowledge:
Best in class: 15-30 minutes
Typical: 1-2 hours
Problematic: Beyond 4 hours
Average Time to Resolution
Ultimately, when a user is requesting support from the helpdesk, they want their issue 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 for help 2 days from now because they are busy and their issue is low priority, you don’t want your resolution time to be dragged out 2 days.
Instead, your SLA resolution time is measured by the time you spent working on the ticket itself.
Industry benchmarks for time to resolution:
Best in class: 30-60 minutes
Typical: 1-2 hours
Problematic: Beyond 4 hours
Customer Satisfaction (CSAT)
CSAT is a crucial metric to monitor. Broadly, this metric serves as 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 feedback rate is likely to be very low. Less than 5% of tickets will get feedback. A single-click CSAT system will yield a much higher feedback rate 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.
Target greater than 85% positive feedback. Industry best in class is over 95% positive feedback. Monitoring this metric at both a global level and on a client-by-client basis will provide significant benefits.
If you’re not using negative surveys as a trigger to reach out to users, you should. This powerful practice demonstrates to users that you are listening to them and can generate goodwill, encouraging more feedback.
For further insights into how CSAT impacts your business, check out our podcast episode: ERP104 - Advanced Project Management.
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. This metric is crucial for ensuring your team can 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 can crush your performance numbers and also create significant psychological stress for the team, as they see the number of open tickets growing.
Counterintuitively, the best approach to increasing your kill rate percentage isn’t always “doing more.” An easier approach is often doing less! Many IT companies suffer from bloated processes and low-value busy work.
I challenge you to analyze the workload of your service team; it’s likely that 10-20% of the work being done isn’t serving you or the customer.
As a benchmark reference:
Tier 1 techs should be completing 10-20 tickets per day
Tier 2 techs should be closing 5-10 tickets a day
Tier 3 techs should be closing around 5
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, while the typical number is around 1.5 tickets per seat. You should target 1 ticket per seat per month. This is generally attainable.
It’s common to see some clients with more than 4 tickets per seat. These clients should be scrutinized to determine why they are so noisy. The most common cause is often a non-standardized environment. The less uniform the client environments are and the more they drift from your defined tech stack, the noisier they become.
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 move through the service desk smoothly. Ideally, tickets are never more than 7 days old, but this isn’t always typical. Setting a target for the number of tickets over 30 days old is a great way to create a review process for those tickets.
Review 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 ruthless with the old tickets. Often, they can be closed.
Stale Tickets
Stale tickets refer to tickets that have not been updated for a period, usually three or four days. Establishing an expectation that techs keep their tickets updated every 3-4 days helps ensure they are more accountable for driving tickets to resolution.
For practical reasons, techs should not have more than 20 support tickets assigned to them at a time. If they have more than 20 tickets, it becomes difficult to keep them updated. Ensuring tickets don’t become stale for weeks provides a system that increases communication with the user.
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 reactive support ticket with more than 4 hours of time should be reviewed weekly to understand what is required to drive it to resolution.
If you are able to catch these tickets earlier with other metrics or processes, that’s great. But once they exceed 4 hours, you need to be diligent about steering them toward resolution.
The power of numbers
Service management is complex, with competing interests and a dizzying number of data points to manage 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 service managers to spot trends and manage exceptions.
Know your KPIs, define your baseline expectations, and step in to assist when those KPIs begin to drift outside acceptable ranges. This is a more scalable way to keep tabs on service delivery without becoming overwhelmed.
