How to Structure Customer Requests Workflows Effectively
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, right…Is 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:
The volume of alerts that can be generated in a short period of time
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:
The administration of Monitoring labor under Service Agreements (to be discussed in the third article in this series).
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 Author’s Skill Set; but we are Here to Help. Email SBuyze@SBuyze.com, and 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:
Non-Scheduled engagements
Scheduled engagements
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 Added, which 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:
It makes it clear who owns the communication and who is responsible to make sure updates are sent to the Customer.
It identifies who knows most about the requests- Urgency and Impact (and next steps).
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 you…however, 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 a 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 initiation, planning, execution, 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 visits) is 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 insightful. If it has sparked any conversation, opposing views, questions or concerns, please let us know by replying to this article or by emailing sbuyze@sbuyze.com. 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.