Why Service Managers have the Hardest job in the world, and what you can do to fix that!!

  • by

I am convinced the hardest job in the world to explain, and to do, is the Service Managers 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 single answer. But, there are 11 Service Delivery Operational workflows from New to CompleteThat 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 workflowsWithout 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.)   

This may be great for Enterprise IT, but this is not enough for MSPsWe 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 answers to these questions are needed before we can move the request from New to Complete in the most efficient mannerNot 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 doWe dump all requests into a queue, tell the techs to deal with it, and the Service Manager to manage itWhich means keeping the Customers happy by meeting contractual and non-contractual obligations, meeting Industry Standard Metrics, and oh by the waymaximizing 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. 

path to msp success

The Solution to Service Delivery Management Issues 

What is the solution 

First, Pause (see the Wikipedia definition 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 workflows are… 

  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 customizableWe could use Ticket Category, but that is using a big part of the software as an identification fieldWe could use Issue and Sub-Issue, but it can be “Not Required” and confusingStatuses 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 overlookedThe 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 CompleteYes, everyone knows where the priority field is, but very few people change it. WhyBecause 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? 


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

  • Talk with the Techs and get their buyin 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.”

Please follow and like us:

Leave a Reply