If you’re in the IT biz, you are most likely familiar with “interrupts” in the CPU. To be safe however, let’s define CPU interrupts as “an activity that stops whatever the CPU is currently working so that it will begin working on something else.” The most common example of an interrupt-driven process is the network card (NIC) in your PC. Every time a packet comes in, the NIC interrupts the CPU and says “hey, I have some packets here, and I’ll forget them when the next packet comes in.. you should do something with this data, like, really soon.”
Interrupt-driven work is, by its nature, low bandwidth/low latency. That is, interrupt-driven work ensures urgent actions happen quickly, but sacrificies the ability of the CPU to do a lot of things because the CPU is, well, being interrupted constantly. But that’s okay.. because we only reserve interrupts for high-priority activities. All other activities are properly queued and scheduled, maximizing the potential of the CPU, system bus, etc, etc.
Smaller MSPs tend to take the “interrupt-driven” approach for all tasks, not just urgent tasks. This is their downfall and one reason why smaller MSPs fail to scale well. In almost every situation, as an MSP scales, it must STOP being interrupt-driven and shift into a queued, scheduled work model (the “dispatch” model).
Let’s go through some examples where an MSP falls into the interrupt-driven trap and what it causes.
Your techs answer the phone
This is the #1 reason why your tier 2/tier 3 techs are unable to get things done. They are constantly being hounded by clients and vendors, and they don’t feel comfortable in ignoring the phone. Every phone call is an “interrupt” that likely leads to an extended, and wasteful, use of the tech’s time.
BETTER SOLUTION: Hire a technical customer rep (very specific requirement for this, read more here) to answer the phone, do triage, and implement a quickfix-style process. Information should be handed to your higher tier techs, instead smaller MSPs point a firehose at their team.
Your techs read emails from clients
Why do MSPs let their techs do this? This is almost as bad as techs answering the phone (I wrote a whole blog on why tech’s shouldn’t answer the phone). There is a small advantage here that techs are generally really good about batch reading emails, so there is some efficiency there, but emails are still interrupt-driven.
BETTER SOLUTION: Techs should go through their email every morning and clear it out. Maybe. Even that often is debatable. But your helpdesk PSA should be the “email” system. Ensure techs communicate with clients via ticket notes (in Autotask, these are easily sent as email) and that client replies are going back into the ticket. The PSA should set a ticket with a new client response using a status like Mail Reply. (More on this later.)
Your techs work tickets
You have a shocked look on your face. I can see it. Your techs should NOT work tickets. Tickets are buckets of information, including notes, time entries, random CC’s, and often worse. When a tech starts “working a ticket,” what they are actually doing is re-reading their notes, trying to catch up with where they left off, ramping up mentally on status and next steps, etc. What a waste of their time!
BETTER SOLUTION: You don’t “work a car,” you “change the oil.” You don’t “work a fridge,” you “open the fridge door.” Don’t noun your techs. Verb them. Tech work should be via scheduled activities (in Autotask, these are called Service Calls). The activities should be in order of priority and ticket age. So instead of “work these 3 tickets,” they “work activity #1, activity #2, and then activity #3.”
Your techs look at lists of tickets
Don’t get me started! There are so many issues with the idea that techs should even see a list of all their tickets. What exactly does that do except force them to think through prioritization, which ticket has a new update pending their response, etc.
BETTER SOLUTION: The tech’s way is their dashboard. There is no other way. That IS the way. All modern PSAs allow you to use pre-built, or, based on your sophistication, customized dashboards that feed the tech some work. (By the way, we solved this in our Autotask integration with the Engineer WorkBoard to give you an idea of how to streamline what your techs see.)
In Autotask, a tech should see this on their dashboard:
- Their sorted list of service calls/work to do
- If you don’t have a dispatcher doing this: a widget showing Tickets in Mail Reply
- A comparison of their completed work vs their goal and their team/team goal
Think about it: this dashboard says “here is your work, here are responses you are waiting on, and here is how you are doing, keep up the good work buddy.”
Giant Rocketship
Want to automate even more of your MSP? Try rocketTask to turn recurring tickets into a business advantage, and Flight Deck to automate dispatch/scheduling/escalations for your team. Focus on what you do best, automate the rest.
