Help! What do I do? Use a Triage Queue!
“Doctor, Doctor, I can’t breathe!”
“Well, I can stop that...Quick, call 911.”
“OK, what is the number?”
As in the medical industry, Triage is no joke. We depend on the medical industry to quickly decide if we’re dying, contagious, in pain...or even in the right medical facility. I hope you have not had to call your doctor or any medical specialist lately, but if you did, the first thing you would hear is “If this is an emergency, call 911” (I’m not sure if this is the same worldwide or how widely known this is, but 911 is what we dial here in the US to call for emergency help.) I have never been in a situation where I needed to call 911, but I am sure the first question is to determine, “Is this a medical, police, or fire emergency?”
In the case of MSP’s, it is all three.
Just imagine the chaos, disappointment, stress, and financial ruin if every 911 call was responded to by a lone police car, whenever it got around to arriving on site. How would they handle a car accident or heart attack, let alone putting out a 5-alarm fire (I am not even sure what a 5-alarm fire is, but it sounds pretty dramatic on TV)? And yet many times in the MSP industry, we do exactly that. We just dump the Customer requests in a queue and have a free-for-all (sometimes called a Ticket killing party). Click here to subscribe and download your very own copy of our Triage SOP[/su_note]Is there a better way? YES. Read on...
MSP vs. Medical: How do they compare?
The Triage process for an MSP is very similar to the medical industry. We have: - Incidents – Emergencies
Critical – Heart Attacks
High – Cancer
High-Backup – Asthma
Medium – Broken Bone
Normal – Cold or some sort of allergy
- Service Requests – Go see a specialist
Quick Hits – Hearing tests and battery replacement
Minor Service Requests – CT, MRI, and all those tests that end in “-oscopy”
Major Service Requests – persistent sports injury requiring outpatient surgery
Installs – Cosmetic Surgery
- Projects – having a baby - Recurring Visits – Routine, regularly scheduled family doctor visits Unlike the medical industry, for an MSP, it is best if all the Customer requests go to an Easy-To-Do-Business-With single location. Thus:
Customer Service
Dispatch
Service Coordinator
TRIAGE, etc.
Regardless of the title, we need an effective process to intake the Customer requests and funnel them into the proper engagement workflow (Incident, Service Request, Project, or Recurring Visit). For today, we are calling that process Triage. But which is the optimum way to Triage a Customer’s request?
The BEST way to Triage a Request is to...
Start with the goals:
To process the request into the proper workflow – Incident, Service Request, Project, or Recurring visit.
Clean up the information, and/or request more information, so all the info the Tech needs to be able to engage is in the ticket.
Code the ticket properly, so all stakeholders know exactly what the request is and how it is to be processed.
Assign (maybe schedule) the request so...
You don’t disrupt other requests.
The Customer knows what to expect (Customer communications is the next few articles).
The Techs can face forward and not be slowed down to ask questions or require discussion.
As a side note, Autotask Ticket Categories are highly customizable. I encourage you to sit down with your Team and pull the Ticket detail panel fields (left side of the Ticket). Those that are edited most often, to the top, those that are seldom touched, to the bottom, and those never used, hidden. It’s also a good idea 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. You should have a different category for each stop along the way, as different information is needed at each stop.
Here’s how to tackle the Triage process:
1. Account: Make sure the Ticket is in the right account name.
2. Contact: Make sure the contact is in the database and in the ticket.
3. Description: Clean up the description -
Remove any information that is already in the ticket
- Internal Employee name and contact info
- Customer contact info
- Signatures beyond the contact name
- Disclaimers
- Normal niceties: Hello, Bob, Sally, etc. (keep the unusual niceties, the ones that show being Wowed or Upset)
Keep important information
- Name of the requestor
- Date/time stamp of when the request came in
- Facts pertinent to the request
4. Title: Now that the Description has been cleaned up, change the title to accurately reflect a summary of the request.
5. Priority: Is the best way to segment the request into one of the four workflows (Incidents, Service Requests, Projects, and Recurring Visits).
Hint: almost no Project or Recurring visit requests will come in via the Email Processing. When they do, the request needs to be routed to the Account Manager ASAP. The message to the Customer is: “Those types of requests require a conversation with the Account Manager, who has been alerted and will be contacting you soon.” That leaves Incidents and Service Requests. A quick test of which one is asking the question:
“Was the device, network, or user working in the past - and is it now broken?”
If so, then it is an Incident and needs an incident sub-priority of Critical through Normal. If it is not broken, then it is a Service Request and needs a sub-priority of Quick-Hits through Installation. Incident sub-priority is determined by an Urgency and Impact matrix, whereas Service Request sub-priority is determined by estimated hours to complete. Quick-Hits take less than an hour, Minor Service Requests take less than 4 hours (1/2 day), Major Service Requests take less than 8 hours (full day), and installations take more than a day but are less than the Project threshold.
6. Statuses: The next step is to determine if we have all the information needed for the Tech to engage. If not, set the status to Request for Information. Then, forward the edited, pre-formatted notification to the Customer, requesting the information needed to enable Tech engagement. If all the information is in the ticket, then decide if the Tech can engage at will (Ready to Resolve) or if it needs to be scheduled with the Customer. If scheduling is needed, pick up the phone, and negotiate a time before the Resolution Plan SLA when the Customer is available. Once the date and time is agreed to, determine if the scheduled visit is on-site (Dispatched – On-Site), or if it can be done remotely (Dispatched – Remotely). If your Service Coordinator uses any other Statuses, please email me because you most likely have tasks that are leaving requests in a black hole and not pushing for completion.
7. Primary Resource: is assigned by the Service Coordinator as part of the triage process. They should be provided with a Skill and Availability spreadsheet showing each Tech down the left side, and the Technology Stack and Availability across the top.
For each Tech and Technology, they 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 the technology’s Knowledge Expert and expected to keep up with how the technology is changing. Availability designates On-Site and at which location.
Role: Great 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 my experience is with everyone, their pick stays with them over the life of the request.
Note: Retention is a huge conversation in the industry redirect. Career growth is one of the best ways to retain top talent - better than just throwing money at them.
8. Secondary Resources: For the most part, this is left empty. There are times when a Secondary Resource needs to be assigned, mostly in Project scheduling.
9. Work Type: Great thought and planning should go into Work Types as they drive billing and Contract Exclusions. After determining the best Work Type 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 my experience is that with everyone they pick, it stays with them over the life of the request.
Note: In an optimized Service Delivery environment, these 9 fields are the only ones needing to be Triaged to move the Customer’s Request along in the process. Once this is achieved, it is very easy to Triage a request within 20 minutes, provide the Customer with a helpful 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 is hidden in the Triage Ticket Category.
10. Estimated hours: In the beginning, this is a best guess. After turning on Issues and Sub-Issues, estimated hours can be based on the historical data for each sub-issue. Once this has been implemented, it can be automated, at which time, this field should be hidden.
11. Queue: can be automated based on status. This field cannot be hidden, so it should be moved to the bottom of the detail panel.
12. Issue & Sub-Issues: These fields are not ones I would be using unless they are being reported on. If they are being reported on, then the Sub-Issue should be the device level. When it gets 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 sets is what the ticket will show for the life of the ticket.
13. Source: this field can be automated and, therefore, should be hidden.
14. Due Date: should be locked down by SLA, the project category, or recurring master. This field should be hidden.
15. Configuration Item: should be hidden. If it can be auto-populated, then it should be in the Ticket Category the Techs use, but not in the Triage Ticket Category. Very few Service Coordinators can figure out the configuration item. My guess is, even if they can, it is a lot of work and their best guess would be misleading.
16. Contract and SLA: 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 the Contract Category is empty completes the automation process. Once these are in place, this field should be hidden in the Ticket Category.
17. Service: This field is often ignored and hidden, so that is how we will handle it here. However, to really understand profitability of the Managed Service Agreements, knowing which Service is making money and which is losing, this field needs to be utilized. Especially when Reactive Hours per Endpoint per Month (RHEM) is employed.
18. Purchase Numbers: are seldom used and should be hidden in the Triage Ticket Category. This is the end of the Autotask Standard (non-editable) Ticket Category fields that come from Autotask. I would encourage you to explore the hidden fields available as well as the insight panel to find information that is useful to the Service Coordinator in Triaging the ticket. Once this process is in place, semi-automatic Customer-Facing communication is possible – stay tuned as we delve into that area next... Click here to subscribe and download your very own copy of our Triage SOP.