The Major MSP Industry Dilemma: MACs, IMACs, & Autotask
service requests
We (the MSP Industry) are in deep trouble.
We have a major dilemma.
For years we have let confusion, chaos, and dysfunction reign in our ranks. Why? Because of our “Get’r done” mentality. In other words, we do it to ourselves.
Now to be fair, there is one thing we do very well and that is Break/Fix, unless it comes to our own Service Delivery processes.
When was the last time you ran an RCA (Root Cause Analysis) on the ticket backlog? I mean, rather than asking what to do with the backlog of tickets (Incident tickets more than 7 days old, and Non-Project Service Request tickets more than 30 days old), ask yourself, why do we have a backlog in the first place?What is the Root Cause of not getting these tickets done as expected?
3 Reasons Tickets are Not Completed as Expected
My guess is that if you would analyze why a ticket is not being completed as expected, you would find one of three reasons:
The Techs are unsure what to do about this type of Customer request, so they skip over it in their cherry-picking ways.
It was assigned to the first Tech in the pecking order, who is tooembarrassed that he doesn’t have the right skill to complete the work, so he doesn’t “escalate” the request as expected.
There is not enough time at the moment to complete the request, so it sits there until there is enough time to make their effort worthwhile.
Hint: There is never enough time to work on a Customer’s request over 3-4 estimated hours. So, they get stuck when they are just dumped into a queue with the expectation that the Techs will figure it out.We have now come to the point of this article... For years we have been writing that Service Request tickets need further Triaging. It took years to figure out the most efficient way to address Service Requests. Scheduling blocks of hours in a Calendar just because something is not an Incident does not make sense.
First of all, it is hard to schedule a Service Call for less than 2 hours, and if the Quick Hit Add or Change takes less than 30 minutes, then there is the potential of an hour and a half being wasted. Actually, the Parkinson Principle is at play – give a Tech 2 hours to do 30minutes of work, and they will take the 2 hours to do it.
So, the dilemma is: how do you schedule enough time to complete the work with quality (think more than just reopen rate) in the minimal amount of time? The answer is to figure out how to mix Service Requests in with Incidents and have them swim together within the Customers’ expectations.
Not All Customer Requests Are Created Equal
But this introduces a new problem. Not all Customer Requests are created equal and, in this case, not all Service Requests are created equal. By doing RCA on the ticket backlog, you will find that most of the backlog tickets are Service Requests that do not fit in an Incident Workflow, Queue or Widget. I’m guessingthe majority of the Service Request tickets are stuck there because “There is not enough time at the moment to complete the request, so it sits there until there is enough time to make their effort worthwhile.”
Hint Revisited: There is never enough time to work on a Customer’s request over 3-4 estimated hours. So, they get stuck when they are just dumped into a queue with the expectation that the Techs will figure it out.
Based on our experience, we have found that Service Requests taking more than 3-4 hours to complete do not fit and need to be scheduled in the calendars. To find out what the magical number is for your MSP, you could talk with the Techs or bring data. Take a look at the list of Service Request tickets completed over the last 30 days and see which ones are being completed as expected and which ones are lagging. The lagging ones are over the threshold and need to be scheduled.
Note: This is still the Techs communicating, but they are speaking with their actions rather than with their thoughts.
The Difference between Minor & Major Service Requests
For years, we have been writing about the difference between Minor and Major Service Requests. Or in other words, the difference between the ones that fit in the Incident queue and the ones that don’t.
The reason we are writing on the subject again is because we have been miscommunicating. I use the terms Minor and Major Service Requestbecause they make sense to me. Based on the number of times we have been compelled to write on the subject. I would have to say we feel like we are still not communicating. So, we are going to give this a try one more time.
Service Requests equate to Moves, Adds, and Changes (MACs). I have resisted qualifying them this way because the list seems to limit and I am afraid there is another type of Service Request that the term MACs does not cover, but I cannot think of one. We have already split Installs out of our reference to Service Requests, so that is why we are not talking about IMACs.
So, going forward, here is how MSPs should think about Request Segmentation and how we will be communicating:
Quick Hits = Adds and Changes that take less than an hour to complete (A/C <1hr)
Minor Service Requests = MACs that take less than 4 hours to complete (M/A/C <4hrs)
Major Service Requests = MACs that take more than 4 hours to complete (M/A/C >4hrs)
I hope this helps. You might be wondering why this subject and this slight change merits 1091 words.
The reason is the impact on Resolving Service Delivery issues is huge. The “put it in the queue and let the Tech’s figure it out mentality” is the #2 cause of all the Service Delivery Issues causing aBarrier to Growth, Churn, Resource Underutilization, and lost profit.
How do we know? Because we have 22+ years of MSP Service Delivery Coordinator/Manager experience on staff, and 22+ years Autotask System Administration experience. Which is another way of saying we have been there and done that, and we know how to leverage the Autotask software to Resolve Service Delivery Issues.
P.S. Message me for the #1 reason, as I am happy to talk about it.