Fundamental Tips to Triage Support Management

Welcome back! This week, we’re continuing to work through our series on the 9 fundamental areas of IT Service Support and Delivery.   This is the second article of the third fundamental area - Service Level Agreements and Scheduling Objectives. In the last article, we explained how ITIL divides Priorities into two work groups: Incidents and Service Requests.   

IT Service Managers: Customer Service or Triage Queues? 

 Customer Service or Triage Queues are a bridging section between Incidents and Service Requests. Why? Because they are a fundamental area that refers to the intake of Service Requests. At the point of intake, it is not yet known if we are providing Service to the Customer for an Incident or a Service Request.  In practice, there are two different Service Request workflows. There are those that use:   

  1. Customer Service (non-technical personnel) to intake Customer Requests 

  1. A Triage Queue (Technical staff) 

 Note: One workflow does not seem to be significantly better than the other.   

Which model - Customer Service or Triage Queue - works better? 

That’s a regular question that pops up in the MSP-Ignite Service Manager Peer Groups. While there is a lively discussion from both camps, there are some IT MSPs that have tried both.   Sometimes what it really comes down to is - who is on staff. If the non-technical staff is very “non-technical,” then Triage Queue seems to be the way to go. If the Technical staff is very “non-service” oriented towards the Customer, then the Customer Service workflow makes the most sense.  When using the Customer Service workflow:  

  • First Response is when the Technician puts the ticket status “In Progress” and the Resolution Plan due date is tied to the Resolve due date. 

In the case of a Triage Queue:  

  • First Response is when the Triage Queue Technician Triages the Service Request 

  • Resolution Plan is when the Technician puts the ticket status “In Progress” (and is the metric used to meet Contractual Agreements) 

  • Resolve is an internal service request completion goal 

 

Which Model is Better isn’t Black and White 

 I don’t want to give the impression that this is all black and white. While the staff’s skill set may be the strongest deciding factor, how to manage the Customer’s request communication is also important.   Under the Triage Queue model, we do not want Techs disrupted from focusing on Customer-Facing pain to deal with a noisy vendor, or explaining to a caller that the local “Outback Steakhouse” has closed and we now have their phone number.   Tips for using the Triage Queue: 

  • Encourage Customers to submit Service Requests via Email Parsers, Client Portals, or via Agents on their desktops 

  • Have phone calls go to the front desk 

 

Shifting from Reactive to Proactive…With a Little Help 

As a side note, when I arrived at Systems Engineering in 2010, the Customer Service team was very reactive. We moved to a proactive structure and used HDI Customer Service Representative training to help us get there.   After searching for many months, HDI the Association of IT Support Professionals was the best soft side of IT training I could find. I believe it is still the best, and highly recommend it for all IT Customer Service personnel and Techs covering the Triage Queue and/or interfacing directly with the Customer (Help Desk and Engineers).  

Ensure Your IT MSP is “Easy To Do Business With” 

 When considering using the Customer Service model or Triage Queue model, “easy to do business with” in the eyes of the Customer should be a top priority.   Easy to do business with leverages the Single Point Of Contact (SPOC) concept whereby the Customer only needs one phone number, email address, or portal to submit service requests.   The MSP should work hard to help the Customer navigate their organization. The “on-us” means that the Company must get the Customer the proper level of service ASAP, and should coach the Employees not to push back on the Customer. By pushback, I mean asking the customer to call another number or use a different email address.  

The Concept of a Single Point of Coordination  

 While we are talking about a Single Point Of Contact, let me muddy the waters by introducing the concept of Single Point of Coordination (SPoC).   Single Point of Coordination is required when intaking and/or scheduling Customer requests. If two people are responsible for assigning tickets or scheduling service calls, a conflict will arise leading to disruption, confusion, delay, stress – or, in other words - chaos.   The best way to avoid this situation is to have a Single Point of Coordination. That SPoC should not be the Technician who is being assigned or scheduled.  Now it’s your turn! I’m curious - which method does your MSP use - the Customer Service or a Triage Queue model? Let me know in the comments section below!