Service Managers' Job Challenges & Solutions

I am convinced the hardest job in the world to explain, and to do, is the Service Manager’s job with an MSP.The fundamental reason for the insurmountable task is that we are looking for one answer – how to manage the Service Delivery Operation from New to Complete. 

If Only It Were as Easy as a Single Answer…

Here’s the problem: there is not a single answer. But, there are 11 Service Delivery Operational workflows from New to Complete. That is to say, a Service Manager is responsible for 11 different Operational Workflows with one thing in common:They all start out as“New” and end as “Completed”.The Customer’s journey between these two points, however, can take one of 11 distinct paths.It doesn’t stop there.There is also no clear consensus on how to identify, label, or manage the 11 workflows. Without these three key attributes, the Service Delivery Issues will always be blocking the MSPs growth.The Service Managers hands will be tied, preventing them from doing the job they love to do, as expected.

For MSPs, Two Groups for Customer Requests Just Isn’t Enough

Some time ago, ITIL divided Customer requests into two groups: 

1. Incidents (Break/Fix, Reactive, Not working, etc.)

2. Service Requests (Service Requests, Change Requests, Installs, Projects, Technology Audits, etc.)

path to msp success

This may be great for Enterprise IT, but this is not enough for MSPs. We deal with many more types of requests, all at the same time. To say a request is an Incident does not answer the questions about Urgency and Impact or Customers’ written or unwritten expectations.It doesn’t answer whether or not they are Managed or Unmanaged Service Customers, either.To say something is a Service Request does not answer the question about a reasonable engagement/completion time frame, or the best way to engage and proceed to completion. The answersto these questions are needed before we can move the request from New to Complete in the most efficient manner. Not only in its respective discrete workflow - but also to keep a new request from creating a train wreck with the requests already in place on the dashboards and calendars.So, what do we do? We dump all requests into a queue, tell the techs to deal with it, and the Service Manager to manage it. Which means keeping the Customers happy by meeting contractual and non-contractual obligations, meeting Industry Standard Metrics, and oh by the way…maximizing profitability too.Are we starting to see a problem here? Does this not sound like a chaotic free-for-all (and therefore an impossible job)?This is exactly why I say the job as an MSP Service Manager is the hardest job in the world.

The Solution to Service Delivery Management Issues

What is the solution? 

First,Pause (see the Wikipediadefinition since this word is not in the MSP dictionary), Triage, and move the request into the right Workflow with the right SOP / SLA / Tech / and either a dashboard or calendar view, which means: divide Customer requests into 1 of 11 Workflows. It has taken 7 years working for an MSP, with more than 25 years of successful experience, to identify the most common Service Delivery Workflows, or more importantly, the groups of Customer request types that need their own SOP and have a unique SLA.

The 11 MSP Service Delivery operational workflowsare…

1. Critical

2. High

3. High – Backup

4. Medium

5. Standard

6. Quick Hit

7. Minor Service Request

8. Major Service Request

9. Installations

10. Projects

11. Recurring Scheduled Events

Now you may be wondering how to do this in the Professional Services Automation software we pay so much for.That’s a great question.Ticket Type is hardcoded and not customizable. We could use Ticket Category, but that is using a big part of the software as an identification field. We could use Issue and Sub-Issue, but it can be “Not Required” and confusing. Statuses are used to journey map the Customer’s experience from New to Complete, so it seems out of sync to also use them for workflow identification.My guess is priority has been overlooked. The reason I say that is because most (90+%) of tickets come in as Medium and stay that way for the life of the ticket from New to Complete. Yes, everyone knows where the priority field is, but very few people change it. Why? Because it has very little meaning and is not used to drive the Service Delivery process.Wait a minute, you mean we have a field that everyone knows, is used very little, serves no great purpose, but is required on all requests? Doesn’t that sound like the perfect field to segment customer requests by?YES!

So, what is your homework? Here’s what to do next…

• Click Here to Download the Tech Priority Change Communications document.

• Talk with the Techs and get their buy-in that more Priorities are needed to divide the work, so each workflow can be optimized.

• Add the additional 7 Priorities.

• Build the Tickets Created this Week by Priority widget and make sure that when a new ticket is Triaged (I know it is a new word, here is the Wikipedia definition), all priorities are used, and the Ticket does not retain a medium priority for no reason.

• Check-in next week, as we start guiding you through how you can optimize the Service Delivery journey of Customer's requests from Intake to Completion.

…Or as one MSP put it: “Remove the Service Delivery Issues that are a barrier to growth."