At the emergence of the managed I.T. services industry, many service providers wanted to address the number one issue plaguing the industry: slow response time. Under the traditional “break-fix” service model, technicians were constantly being dispatched to customer locations, fighting fire after fire. This meant that customers had to wait until a technician became available, which often meant waiting days for support. However, the managed I.T. services model promised to solve this slow response time problem by focusing on recurring services that help reduce the number of “fires” and therefore allow for technicians to be more responsive to customer needs. While this new service model wasn’t exactly the silver bullet to the response time problem, it did prove to be a step in the right direction, especially for mature managed services providers (“MSPs”) that truly embraced these new operating principles. Arguably, response time wasn’t the actual problem or desire of the customer, though.
The Quick “Response Time” Experience
If you contact multiple MSPs and inquire about their services, most if not all of them will claim to provide industry-leading response time to your service requests. This has been the focal point of the managed I.T. services industry for over a decade. While customers specifically ask for fast response times, and service providers cater their operations accordingly, customers are left dissatisfied at the end of the day. Let’s see if we can pinpoint why in this hypothetical service request scenario:
- 9:00 AM Monday: Jane, the Controller for XYZ Company, tries to log in to QuickBooks but receives an error message that she doesn’t understand. Nearly all of Jane’s work takes place in QuickBooks, so she needs someone to help her as quickly as possible. Jane submits a service ticket to her I.T. service provider, ABC Services.
- 9:30 AM Monday: Frank, the support technician for ABC Services, sees Jane’s support ticket. He sends Jane a message saying he’s received her request and will be looking into it. Frank marks the ticket as “Responded,” and Jane is happy to hear how quickly Frank responded.
- 11:00 AM Monday: Jane, getting anxious because she hasn’t heard anything more from Frank, follows up to inquire about the status of her request.
- 1:30 PM Monday: Frank sees Jane’s message. He apologizes to Jane and explains he got caught up with another customer emergency but will be looking into her QuickBooks issue as soon as he finishes.
- 4:00 PM Monday: Jane finally receives a call from Frank, and Frank connects to her computer to look at the QuickBooks issue. Frank investigates a few settings, and does some research, but doesn’t know what is causing the problem. Frank tells Jane he will need to contact QuickBooks for additional assistance.
- 3:00 PM Tuesday: After a few more follow-up messages between Jane and Frank, and some back-and-forth communication between Frank and QuickBooks, Frank is instructed to run the QuickBooks File Doctor utility. Frank connects to Jane’s computer, runs the utility, and magically the problem is fixed.
At the end of this experience, Jane was feeling quite stressed because she effectively lost two days’ worth of work. Frank, on the other hand, was feeling quite positive that he responded so quickly to Jane’s request and was able to get it resolved by the next day.
Response Time Isn’t What You Think
Did this hypothetical story sound familiar? Sadly, this is the experience between a typical MSP and their customer. Ironically, this is because both the MSP and customer focus on response time. With this focus, the MSP’s objective is to acknowledge and respond to customer requests as quickly as possible. Once that acknowledgment is made, though, the pressure is off. Effectively, response time just refers to how quickly the MSP opens its line of communication with the customer.
There are, however, MSPs that take response time more seriously. When their technician acknowledges the request, they are ready at that moment to begin providing service. But once again, if the focus is on response time, there is no sense of urgency once the request has been responded to. In our hypothetical support scenario between Jane and Frank, Frank still would have gone back and forth with QuickBooks for an entire day before solving Jane’s problem.
There must be a better way…
Resolution Time, Not Response Time
The solution is actually quite simple: Focus on resolution time instead. By focusing on how long it takes to solve the problem, the pressure stays on the MSP throughout the entire support scenario. If the support technician needs to contact QuickBooks for assistance, they won’t simply send them an email and wait for a response. Since the technician is working against that resolution time clock, they will seek out alternative methods to engage QuickBooks or another support channel in order to solve the problem as quickly as possible.
The Not So Simple Implementation
While focusing on resolution time seems obvious and pleasantly simple, the implementation of this seemingly small change is quite significant. For an MSP to deliver on fast resolution times, it must implement countless changes to its operations and culture. Here are just a few examples:
- Monitor active support tickets in real time and have dedicated management teams that will intervene if the resolution is taking too long.
- Have a formal escalation process that can engage more skilled resources if needed.
- Hire and retain highly skilled support engineers that can solve problems quickly and efficiently with little to no need for additional support from third parties.
- Implement and maintain extensive documentation of every customer’s technology.
- Provide ongoing education and training for support engineers to continuously increase and diversify their technical skills and knowledge.
- Leverage artificial intelligence and other advanced technologies to reduce manual, time-intensive tasks.
- Reinforce a company culture that focuses on measuring and constantly improving the customer experience.
Since many of these changes require substantial alterations to the company’s operations, human resources practices, and management philosophies, it’s not surprising that very few MSPs today focus on resolution time as their core performance objective. MSPs that have reached this distinct level of operational maturity, such as Digital Boardwalk, spent a decade or more evolving from a response-focused practice to a resolution-focused practice.
Conclusion
At the end of the day, your business needs technical support requests to be solved and completed as quickly as possible, not just responded to. When evaluating managed I.T. service providers for your business, focus on this resolution time objective and probe the MSPs for their strategy for delivering on this expectation. If one MSP claims to have a 15-minute response time but no known resolution time, and another MSP claims to have a 1-hour response time and a 2-hour resolution time, the second MSP is likely the stronger and more mature service provider, despite their slower response time.
This faster time to resolve your requests isn’t just a subjective improvement to your overall experience with the MSP either. Reducing your downtime and interruption has an objective financial return that far outweighs any small difference in cost you might spend for a more mature MSP.
