Cradle to Grave: The Journey of Customer Request Workflows

  • by

Wouldn’t it be nice if you could funnel all the sources of a Customer’s request to a single triage point – while engaging efficiently without chaos and confusion…and as a Best-In-Class IT MSP 

Yeah, rightIs that what you’re thinking? Not so fast! This is 100% possible for your IT MSP. Let’s get right down to business so we can show you how.   

By the end of this read, you’ll know how to channel all the sources of a Customer’s request to a single Triage point, and then parse them out into various workflows (Incidents, Service Requests, Projects, Routine Maintenance). We’ll also cover a brief overview of the journey the Customer’s request takes to completion. 

The Medical Industry vs. An IT MSP 

The infamous Stephen Covey always recommended starting with the end in mind. For this article, the end of the four workflows can be better understood by comparing IT Service Delivery to how the Medical Industry provides services. (See our GMS Live Expert article for the full discussion).  

Here is a 30,000-foot view of the comparison between the two industries: 

  • Incidents Emergency Room visits 
  • Service Requests Family Doctor visits 
  • Projects Having a baby 
  • Routine Maintenance Physicals 

In the medical industry, it’s mainly up to the Customer (Patient) to know whom to call when for various services. At the Managed Service Provider, it makes sense to have a single point of contact and flow all Customer Requests to that single intake point – the Triage Queue.   

The only exception is Monitoring Alerts, which include RMM, Backups, and other machine monitoring alerts. These are best held in a Monitoring alert queue and assessed before further engagement.  

The reason for assessing Monitoring Alerts before triage is two-fold and due to: 

  1. The volume of alerts that can be generated in a short period of time 
  2. The self-healing nature of most of those alerts 

The Monitoring Alert assessment determines if the ticket is a duplicate or no longer needed. If the ticket needs remediation, it should be moved to the Triage queue.  

The benefit of moving it to the Triage queue before engagement is also two-fold: 

  1. The administration of Monitoring labor under Service Agreements (to be discussed in the third article in this series).  
  2. Filters out the Monitoring Alert Noise of the many IT Service Delivery performance reports.  

Many MSPs have had great success with Monitor Alert scripting to filter out the noise and reduce the labor it takes to maintain the networks However, Monitor Alert scripting is outside of this Authors Skill Set; but we are Here to HelpEmail SBuyze@SBuyze.comand we’ll get you connected with an expert. 

Incidents Service Requests flow in three directions 

Post Triage, Customer Incidents, and Service Request requests will flow out in one of three directions:  

  1. Non-Scheduled engagements 
  2. Scheduled engagements 
  3. Waiting 

Dashboards with the respective Widgets can be constructed providing the necessary engagement order, thus freeing up the Techs from the noise of what to work on next.  See the March 8th article – Two Keys to IT Service Delivery Efficiency: Templates & Checklists 

The three Widgets should be sorted (all from oldest to newest) by: 

  • Non-Scheduled Widget by Next SLA Event Due 
  • Scheduled Widget by Service Call Start Date 
  • Waiting Widget by Last Activity Date 

When a Customer responds to a “Waiting” ticket, the status is then changed to Customer Note Addedwhich is a Resolution Plan SLA event with a very tight SLA. This puts the ticket at the top of the non-scheduled widget with a red Status indicator to make it stand out. Exchange rules can be set up to filter out “Thank You” responses, so they do not trigger the Customer Note Added status. 

Escalation procedures are best executed by adding the escalated Resource as a secondary Resource to the ticket.  Thus allowing ownership to remain with the first tech.  

Why? For these 3 key reasons:  

  1. It makes it clear who owns the communication and who is responsible to make sure updates are sent to the Customer.   
  2. It identifies who knows most about the requests Urgency and Impact (and next steps) 
  3. It facilitates the escalation Resource to tackle the next step and send the request back to the original Resource for continued remediation and completion. 

I know this will shock youhowever, sometimes the Customer’s request is not completely remediated in a single engagement. Think about this scenario: The Resource is capable of completing the request  nothing is needed from the customer, and the request won’t be completed in this session. What happens?  The answer is that they put it on hold, the SLA clocks continue to run, and the Resource retains ownership. 

The Difference Between Service Requests and Projects 

Most project requests should come from the Sales Pipeline. However, it is not uncommon for a Customer to get excited, or a Salesperson aggressive and want the work done without  Engineering Review, Scope of Work, or signed proposal.  

The way to differentiate a Service Request from a Project is by establishing an estimated labor threshold. We recommend 16 hours, but I have heard of MSPs establishing the threshold of anywhere between 8 and 32 hours.  

Once the Triage person recognizes that the request is a Project, the Request needs to be forwarded to the Account Manager, who is responsible for creating the Opportunity and shepherding it through the Sales Pipeline.  

(Our initiationplanningexecution, and closeout articles covered how to manage a project, and we’ve got articles on the Sales Pipeline in the works.) 

One final note: an incident going over the project labor threshold does not make it a project. Unfortunately for the MSP, Managed Service Agreement support does at times go sideways and require much labor to remediate or process Root Cause Analysis. This is a reality – and even though it has a negative impact on Managed Service profitability, it still does not make it a project. 

Why Routine Maintenance is Necessary  

Unlike Incidents, Service Requests and Projects, Routine Maintenance requests flow out of a Managed Service agreement. The agreements retain a certain number of hours that are regularly scheduled, and normally at a reduced rate. In “Full Service,” or “All-In” service agreements the MSP is responsible for the network, so Routine Maintenance (Network Administration, Technology Success visitsis required to limit the liability. 

If the Managed Service Provider agrees to maintain the network for a certain fee, it is a good idea for them to be: 

  • Regularly getting eyes on the network 
  • Executing a Preventative Maintenance checklist 
  • Upgrading the network to the MSPs revised Standard Build (Over the year) 
  • Performing other Preventive Maintenance activities 

The best in class MSPs take Routine Maintenance very seriously and use the time to look for Network Upgrades or better ways of configuring the network, which directly leads to sales opportunities (and of course, impacts their bottom line). 

Let’s End on this Note 

We hope you found this overview of the Customer Request’s workflow from Cradle to Grave insightfulIf it has sparked any conversation, opposing views, questions or concerns, please let us know by replying to this article or by emailing 

If you’re not sure if your PSA software is fully configured to support the Customer Request workflow, take the easy PSA Optimization Self-Evaluation checklist to see where you stand.

Please follow and like us:

Leave a Reply