Improve your Service Delivery Performance with a Better Triage Process

triage process

There is a way to dramatically improve Service Delivery operational performance without involving the techs.

If you’ve ever watched TV, you’ve probably seen that insurance commercial where they “know a thing or two because they’ve seen a thing or two” which allows you to quickly recover from a wacky disaster that befalls your car or house. Well, that’s Advanced Global when it comes to the world of MSP Service Delivery. We have certainly seen it all when it comes to Service Delivery and definitely know a few things about putting your MSP on the road to Service Delivery excellence (hint: you need a well-trained Service Coordinator).

Here are several interesting facts from our travels:

1)    If you improve the intake process, the rest of the client journey from cradle-to-grave improves organically

2)    Having a Single Point of Coordination (SPoC) is critical to driving chaos out of the Service Delivery environment

3)    Service Coordinators (SCs) do a better job intaking requests than techs

4)    Proactive, dynamic dashboards benefit the team in several ways:

a.    They know what to work on next

b.    They’re aware of everything for which they’re responsible

c.     They get alerts when a request needs intervention

5)    Proactive, dynamic Service Coordinator dashboards go even further:

a.    Coordinators know if the workload across all techs is in-balance

b.    Coordinators know if the techs’ dashboards are in fine, working condition

The Service Coordinator dashboards can even help with the intake process by:

1)    Alerting when a new request comes in or has been returned for re-triaging

2)    Indicating which requests need to be scheduled

But driving these improvements without involving the techs starts with a best-in-class triage process. This may sound difficult, but we can guide you through the process. For some background reading, here are two great articles comparing our Service Delivery process to those in the medical industry:

Help! What do I do? Use a Triage Queue! — Advanced Global MSP Coaching (agmspcoaching.com)

Parallels Between Healthcare Procedures & IT Service Delivery — Advanced Global MSP Coaching (agmspcoaching.com)

Click here for more info on the Service Coordinator Training Program

Here are some simple steps to Triage a New Client Request:

Goals

1)    To process the request into the proper workflow – Incident, M/A/C (Moves/Adds/Changes), Install, Project, or Recurring Service.

2)    Clean up the information and/or request more information, ensuring all pertinent info needed by the tech to engage is captured in the ticket.

3)    Code the ticket properly, so all stakeholders know exactly what the request is and how it should be processed.

4)    Assign (maybe schedule) the request so:

a.    Other requests aren’t interrupted.

b.    The client knows. (See Client-Facing Communication Recommendations)

c.     The techs can face forward and not be slowed down by needing to ask questions or require discussion

As an aside, Autotask ticket categories are highly-customizable.  I would encourage you to sit down with your team, and pull the ticket detail panel fields (on the left side of the ticket) which are edited most often to the top, move those seldom touched ones to the bottom, and those never used – hide ‘em!  I'd also encourage you to review the options in the insight panel (right side of the ticket).  Look for information that would be useful at each step in the process. 

The recommended Triage process

Here’s the approach we recommend for triaging a request:

1.    Account

Ensure the ticket is in the right account name

2.    Contact

Validate the contact exists in the PSA database and in the ticket itself

3.    Description

Clean up the description

a.    Remove any extra info already listed in the ticket:

        i.     Internal employee name and contact info

        ii.     Signatures beyond the contact’s name

        iii.     Legal disclaimers

        iv.     Normal niceties: Hello, Bob, Sally, etc. (Keep unusual ones that show being wow’d or upset)

b.    Keep important information:

        i.     Name of the requestor

       ii.     Date/time stamp of the request submission

       iii.     Facts pertinent to the request

4.    Title

Adjust the title as needed to accurately summarize the request

5.    Priority

This is the best way to segment the request into one of the five workflows (Incidents, M/A/Cs, Installs, Projects, Recurring Visits).

Hint: Almost no Project or Recurring requests will come in via the email processing.  When they do, they need to be routed to the Account Manager ASAP, and then educate the client that those types of requests require a conversation with the Account Manager, that the Account Manager has been alerted and will be contacting the them (the client) soon.

That leaves Incidents, Installations, and M/A/Cs. A quick test is whether the device, network, or software was previously functioning properly and is now broken. If this is the case, then the ticket is an Incident and needs to have a sub-priority set within the range of Critical through Standard. If it's not broken, the ticket is an Install or M/A/C and needs one of the sub-priorities of Quick Hit through Installation. 

Incident sub-priority is determined by an urgency and impact matrix, whereas sub-priority for M/A/Cs is determined by estimated hours to complete: “Quick Hit” is for A/Cs taking less than an hour, “Minor SR” (Service Request) is for M/A/Cs taking less than 4 hours, ”Major SR” for M/A/Cs taking more than 4 hours, and “Install” is for Installations taking more than a day (8 hours) but less than the Project threshold (ex: 16 hours).

6.    Status

The next step is determining if all the information needed for the tech to engage is present. If not, set the status to Request for Information, and forward the edited, pre-formatted speed code to the client requesting the information needed to enable the techs to engage.

If all the information is in the ticket, then decide if the tech can engage at-will (Ready to Engage) or if it needs to be scheduled with the client.

If scheduling is needed, pick up the phone (or use TimeZest), and negotiate a time (before the Resolution Plan SLA) when the client is available.  Once the date and time are agreed to, determine if the scheduled visit is on-site (Dispatched – On-site), or can be done remotely (Dispatched – Remote).

If the service coordinator uses any other statuses, please email me as there is a risk that requests are sitting in a blackhole and not being pushed to completion.

7.    Issue and Sub-Issue

If these fields are being leveraged, then the Sub-Issue should be the device level.  When you get right down to it, the techs can do a better job coding these fields than service coordinators, but 9 times out of 10, whatever the service coordinator picks is what the ticket will show for the life of the ticket.

8.    Primary Resource

This is assigned by the service coordinator as part of the triage process. The service coordinator should be provided with a skill sheet showing each tech down the left side and the MSP’s supported technology stack and availability across the top.  Each tech and technology should be rated as Basic (incident response), Intermediate (in-training for advancement – capable of service request response), and Advanced.  One of the techs should be designated as champion and expected to keep up with how the technology is changing.

9.    Role

Extensive thought and planning should go into Roles, as they drive Billing and Contract Exclusions. After determining the best Role schema for the company, over-communicating what they are and when to use which one goes a long way in improving profitability. The service coordinator should be very familiar with them as whichever one is chosen stays with the ticket over the life of the request.

Note: Employee retention is a huge conversation in the industry redirect.  Career growth is one of the best ways to retain top talent. It is better than throwing money at the employees.

10.Secondary Resources

For the most part, this field is left empty.  While there are times when a secondary resource needs to be assigned, this seems to happen mostly in Project scheduling.

11. Work Type

Just like Roles, additional extensive thought and planning should go into Work Types, as they modify the Roles and are the primary billing status used by the team. And, not surprisingly, after determining the best Work Type schema for the company, over-communicating what they are and when to use which one also goes a long way in improving profitability.

12.Service

Include the service that covers engagement, or leave this field empty if no available service is applicable.

Note: In an optimized service delivery environment, these 11 fields are the only ones needing triage to move the client’s request along in the process.  Once achieved, it's very easy to triage a request within 20 minutes, provide the client with a rich acknowledgment rather than an automated one, and set the techs up for success.

The rest of the fields can be locked down or automated, and all but one can be hidden in the Triage ticket category.

13. Estimated Hours

In the beginning, this is a best guess by the service coordinator.  After leveraging Issues and Sub-Issues, estimated hours can be based on the historical data for each sub-issue.  Once implemented, this process can be automated, and then this field should be hidden.

14.Queue

This can be automated based on status.  Due to the fact this field can’t be hidden, it should instead be moved to the bottom of the detail panel.

15.Source

Since this field can be automated, it should be hidden.  In the case of a monitoring alert coming in via email be sure to structure a WFR to change the source from email to alert.

16. Due Date

This one should be locked down by either SLA, the project category, or a recurring master, and it should also be hidden.

17. Configuration Item

This also best to hide this one, except in the Monitoring Alert ticket category, where the RMM tool will populate the information.  

18.Contract and SLA

These should all be automated using Default Contract, Contract Exclusions, and Contract SLA.  Using a non-Contract SLA workflow rule to apply the Non-Contract SLA when Contract Category is empty completes the automation process.  Once these are in place, this field should be hidden in the Ticket Category.

Hint: Leveraging the Cascading Contract Automation makes this easy-peasy! 

19.Purchase Number

Seldom used and should be hidden in the Triage ticket category.

These are the Autotask ticket category fields adjusted for the Service Delivery team. I’d encourage you to explore the available hidden fields, as well as the insight panel to find useful information for the service coordinator in triaging the ticket. Simply implementing the triage system above should save your MSP lots of time, increase efficiency, and make happy campers of both clients and techs. Of course, there’s a lot more to improving Service Delivery Operational Performance.

If more help is needed beyond a simple article, Advanced Global offers our Service Coordinator Foundations training for a small investment. This six-week training will help set your Service Coordinator (and, by extension, your Service Delivery team) up for Operational Delivery success. Like I said earlier, we’ve seen a thing or two in our time working in and supporting MSPs. And we’re happy to share!

Click here for more info on the Service Coordinator Training Program

-Steve & Co