Changes in the MSP Industry: Impact Assignment & Scheduling
When to assign and when to schedule seems like kindergarten stuff. I mean it should be easier than writing about Dick and Jane, right?
Not so fast.
Big Changes in the IT MSP Industry
Over the last decade, the MSP industry has seen significant change, mostly moving from on-prem to in the Cloud. Though more subtle, the concept of Assignment vs. Scheduling is also changing. As someone who actually did the work, this is a change observed from the driver’s seat.
To talk with someone who has been there and done that, and is willing to help you sort it out, book a Free 30-minute, no sell Coaching call with Steve.
When I first joined the MSP industry, 100% of the work was scheduled. 80% was scheduled on-site as a competitive advantage against out of market NOCs. Little by little, the techs realized they could do more of the work remotely, so they started leaving their desk only when they absolutely had to.
Over time, the MSP was forced to do more remote work in order to keep pricing/expenses down. This change led to confusion over when to schedule and when to just assign.
Engaging & Completing Service Requests
At first, knowing when to schedule and when to assign was drawn along the lines ITIL lays out for Incidents vs. Service Requests. While this works well, it is not the most efficient way to engage and complete Service Requests.
Moving Service Requests into the assigned model leads to more confusion as to what to work on next. This confusion can be sorted out by extending the Incident SLA Critical, High, Medium, and Normal priority model to include Service Requests, Quick-Hits, minor service requests, major service requests and installs.
But this still leaves the problem of what to do with Incidents and Service Requests that require the Customer to be available at the time of engagement. These will need to be scheduled either remotely or on-site.
Remember to communicate which is which at the time of scheduling so the Customer and Tech both know and stay in sync.
Scheduling Projects & Recurring Visits
No matter what, Projects and Recurring visits need to be scheduled.
Projects, so they are done without crushing the availability to respond to Incident or Service Requests.
Recurring visits, because the SLA engine that is used to sort out “What to work on next” is based on Ticket create date, not due date, and therefore does not fit in the assignment model. However, they do fit very well in the scheduling model.
So…When to Schedule & When to Assign?
Based on my experience, here’s a simple rundown:
When triaging a ticket, the default is to assign a tech and let the Ready to Be Resolved widget sort the order in which the tickets are to be worked on by using the Next SLA Event Due Date.
Tickets requiring the Customer to be available during the engagement need to be scheduled either remotely or on-site.
All projects and Recurring visits need to be scheduled.
Sounds simple enough, but from my experience, it may require a major mindset shift.
If you need a 30-minute sounding board to sort it all out, book a FREE (no sales call, I promise) coaching call, and I will give it my best shot to make it as clear as mud for you.