Hear the article
In today’s post, Paul Azad, the founder of ServiceTree talks about their customers’ experiences. What is the expectation from their customers? And more specifically, what do we want our customers to experience from us?
Expectations
I hear it quite often that when a customer calls, we need to get it straight away, we need to get results straight away. And all those sorts of interconnecting components. Now, it is very true that we do want to be attending to our customer’s requirements and our customer’s expectations. But that whole notion depends on the expectation.
When we talk about expectations, it’s a very hard thing to change once the expectation is set. It’s always said that your first experience is everlasting, which is definitely very valid. But it doesn’t mean that we should be breaking our backs to attend to customer requests in an unreasonable fashion. I was speaking to an MSP about a week ago, and one member of the team was talking about how their customer’s expectation is that they answer their call within 90 seconds. And then somebody actually works on the tickets straightaway until it’s resolved. It was interesting because that was what he thought it was. When I spoke to another person within the business, that actually was the business owner, it was confirmed that wasn’t the case.
Now, on first thought that sounds like a great thing, right? That our customers ask the phone or where’s the phone straight away? And we got to the ticket straight away. Then we resolve it straight away. But you’ve got to actually work out, is that actually possible all the time?
The Importance of Looking at Your Data from a Different Perspective.
Most MSPs, unfortunately, don’t look at their data. And that’s something that I see over and over and over again. And those that do look at their data, look at it from just a very different idea.
When that MSP first talked to me about that, because they were thinking about moving from their current aside or outsourcing to help desk, bringing it in-house. And I was just helping them, consulting with them on what they need to do because they haven’t had it in-house for a while. And also, they’ll actually also consider using Utilizing ServiceTree. But really the ServiceTree component wasn’t really the driver for the conversation. The conversation was about what I need to do as an MSP to bring in-house. So my first thought was when I heard 90 seconds answering and all the way through resolution, my first thought was that, hey, let’s look at the number of tickets that you’re logging per day on average. And then when we sliced it down for the last, actually the last three months, but even when we looked at the last one month, then we looked at it on a day-by-day basis, and then an hour-by-hour basis, and so forth.
The other thing that was really interesting was that the average time per ticket was in the 14-minute range. What that would mean is that if a technician answered the phone at nine o’clock, they wouldn’t get off that ticket until 9:40. Which means that the next ticket that doesn’t really catch realistically, let’s just be very serialized here, that at 9:41, they finished their ticket, the phone rang, and then that next ticket would go all the way through till 10:20. Based on that when I looked at the tickets that were lugging around 500 Odd tickets a week, that’s 100 tickets a day. So if you do the quick maths, and you say that you need to have that 90-second answer all the way through resolution, even if the ticket was only taking on average 30 minutes. That means each hour each technician can only answer two phone calls and resolve two tickets.
Just on those basic numbers, imagine that the customers could be logging tickets exactly at the hour and a half past the hour like it’s a bus service or a timetable on an airliner flying in from out of JFK. So that means that each technician can do two tickets an hour. And let’s say they are 100% utilized, they could do 16 tickets a day. So 100 tickets a day for the MSP. If each MSP technician does 16 tickets, you can already see that you’re going to need at least six technicians just to be able to answer the phones and resolve them. That is all on the assumption that they work on the ticket to the end and so forth.
Now, when I look at the data, I looked at it at the hour-by-hour breakup, and based on that you’re going to need at some times eight or nine people just answering the phone and always being available.
The pain point of not touching tickets at the start.
Why am I talking about this? Because it’s the actual expectation that our customers dictate what we do. Now, the good thing was that this MSP didn’t have these SLAs in place. And I do agree that at times, it’s generally going to be easier if the technician answers the phone, or somebody answers the phone and resolves a ticket on the spot. But that notion always comes back down to the issue that we’ve created within an MSP. And that is that, well, let’s just say if a technician doesn’t work on a ticket at the start, they don’t touch the ticket or work on it later.
I’ve said it before, I’ve had an MSP since back in the 2000s, so I’ve had an MSP for 20 years. And I can definitely tell you, that was a pain point we had up to about five, six years ago. I definitely knew that if a ticket wasn’t touched, when it came in and worked on, the chances that the ticket would get touched or worked on in the next few hours, were not very high, because my technicians would pick and choose what ticket to work on, and so forth. So that was always a big pain point. In all honesty was a core reason why we built a tool that ended up becoming ServiceTree.
The idea that we answer the phone and work on it straightaway, sounds like a great thing. But just think about it, if you’re going to a hospital. It’s the same thing. When you walk into a hospital, they don’t just go get you worked on the straightaway and put you in, see your doctor and all that business. And the reason they don’t do that is they triage the work. They triage the symptoms. When you walk into a hospital, they first see if the issue that you’ve got is life-threatening. And then if it’s not, they work base back on there and work out how important is it that you get dealt with in the next few hours, next hour, next 15 minutes, and so forth. That works really, really well. And yes, if you’re a person that goes in a hospital, or emergency, and you’ve just got a little cut on the side of your finger, yes, you’ll be there for six to eight hours. And that is very painful. But that isn’t a problem of the whole triaging concept. That is a problem that hospitals could be underutilized or under resource.
Having the right amount of capacity to start with.
Now it’s the exact same thing with an MSP. If we don’t have enough resources, that model is going to be the same, it’s gonna be the same issue, as if we’re going to answer the phone call and work on it straight away. The whole idea behind this is that we need to have the right amount of capacity to start with. Having the data to be able to look at your data on a 15-minute time block, so 9 to 9:15, 9:15 to 9:30, 9:39 to 9:45. and all the way through the rest of the day,
you should be able to see how many tickets are being loaded per 15-minute block. And then based on that work out what capacity you need.
It’s a different mindset, we brought on casual or hourly people on my MSP, I would say around 2016, or 2017, and there were university students who wanted some hours of work, and they were junior IT degrees or computer science degrees. And we utilized their services when we were busy and when we had those peaks. So Monday and Tuesday mornings, we’d have some more university students working, answering the phones, and working on the tickets. But overall, if we took out those students, my core team at that time wasn’t as big as it was when it was at full capacity. And that’s really no different to what you see, it doesn’t matter if it’s a supermarket or grocery store. It doesn’t matter where you go. That’s the general way businesses work successfully. And they’re able to balance the requirements from the customers to the bank balance requirements of the business to be profitable to be in business anyway.
The advantage at the moment with COVID is that we have a lot of resources that are looking for a job right and it’s a position that MSPs haven’t been in in quite a long time. There’s no reason why as an MSP you don’t utilize casual labor, hourly labor, doesn’t even have to be in your local city. For most PSAs logging tickets you don’t have to be in the same City as the MSP, as long as a person’s got a good internet connection, has integrity and you trust them to be able to do their job, your data should be able to cover you to see if they’re doing their work if they’re not sure how they’re performing. And that’s really what it comes back down to keep talking about data. But most MSPs, don’t look at their data and have no idea where things are going wrong until it’s at the breaking point.
How do we let our customers dictate what is urgent?
With all that in mind, you are in a position where you can let the customers get what they need if you really want to get them to answer phone calls, and get them all the way to resolution on the first call. I totally am somebody that I’ve seen that model. And I’ve seen the model where we just logged the tickets and our techs get back to the customers based on the priority of the ticket, and that works a lot better. And works a lot better because you’re able to work and balance it out where right at that point in time, if you’re at capacity at that point in time, there’s no way for you to be able to work on any other tickets. Think of the grocery store, when you go in, there are 20 people in front of you, and you’re very, very frustrated, right? Whereas if you were able to load balance that and know that in seven minutes or eight minutes time, you’ll be at the counter and so forth. You could do other stuff and still wait in line, you could still be looking through the aisles and maybe buying something else. It’s the same way the hospitals do it. It’s the same way as other businesses do it.
Just sort of think about that it’s it also comes back down to customers dictating their requirements as well. So how do I run this back through to the beginning? How do we or why did we let our customers dictate what’s urgent? And that really comes back down to what I was trying to say earlier, which is, if a customer is calling through, and we’re just answering their ticket and working on it straight away, they’re always going to feel that that’s the requirement. So when we’re really busy, and we don’t do that, the customer is going to start feeling the need to say, well, this is urgent, I need it done now.
Why deadlines are important.
And not even an MSP, not even your customer, just in general, when somebody puts a deadline in place, the deadline is very rarely a deadline. If you think about it, when you put a deadline in place, for your kids, for anything, it’s very rarely a deadline that has to be done. The reason why you generally put a deadline or something it’s urgent, is because you don’t want to be forgotten about and you don’t want it to be superseded with something else. Just think about the kids taking out the trash. I want you to start the next five minutes, what’s the chance that you need to take the treasure and the next five minutes? Chances are, it’s not required to be done next five minutes. But you know if it’s not done in the next five minutes, your kids will forget about it, and it won’t be done for another couple of hours, and then you’ll have to do it yourself.
What’s urgent and what’s realistic
It’s the same thing with our customers that if we let them dictate what’s urgent, then everything’s urgent for them, and we’ve got to bail and balance that out with what’s urgent and what’s realistic because if you’re just doing tickets as they come in, I can tell you factually, you’re gonna need to have a lot more technical staff or labor resources to make that happen. And yes, it is definitely possible, but it’s also not very profitable.
You don’t have to be a big MSP to be profitable.
And that’s what’s happening in the current market. With the way COVID is affecting MSPs, the ones that have really struggled, the ones that are unfortunately out of business, are the ones that have been not only hit by customer downturn, because that’s realistically impacting everybody. But it’s the ones that didn’t have any financial security to start with, the ones that didn’t have the profitability to start with, to make it through this. And you don’t have to be really big, I’ve said this before, you don’t have to be really big MSP to be profitable. During my MSP until early 2019, we had about 50 staff and over 10,000 endpoints, and was quite profitable. Today, my MSP is down under about 750, maybe 760 endpoints at three full-time or not even really three full-time because now that I think about it, it’s really two full-time and one resource that does work in my MSP and in ServiceTree. And you know what? My profitability is still there now. Definitely, you have more money to move and more money to play with when it’s bigger. But your profitability doesn’t really change as a percentage, when you get to those sizes, it becomes a lot harder to maintain. So don’t think that a large, MSP is going to be a lot easier because they generally have a lot higher costs to run their business.
The way that I see it now, some of my bills that I am, what things cost me for a whole year is what I used to spend in less than a month beforehand. There are two sides to that same sword, so don’t think that profitability is only going to come when you become a large MSP. You can be quite profitable, even with 750,000 endpoints. But that really does come back down to ensuring you get your process in place. You don’t let your customers dictate what’s urgent and how you do things because that has got a really, really huge I can’t say enough, it’s got a huge impact on your profitability, and again, your customer experience.
