Dispatch Data for Amazing Service Delivery

Dispatch data for amazing service delivery

One of the keys to a high-performance help desk is managing the flow of tickets through the service queue. The quality of your service as an IT provider will often be judged not by if you can fix the issue, but the experience that the user has while you do your magic on the back end.

Think about the last time you went out for a nice dinner. I’m sure the food was great - that’s why you choose a place with great reviews and a high price tag. So what differentiates fine dining from casual dining? It’s often the experience.

Consider the user experience for your clients when they open a support ticket. Is it the equivalent of a casual diner or fine dining? BrightGauge can help ensure the client experience is managed like a 5-star restaurant, differentiating you from other IT providers that are simply providing a sandwich shop experience.

Dispatch Role

The first point of contact for your clients is usually managed by a dispatcher. I personally don’t support the idea of a pure dispatcher role like some in the industry advocate for. I find this is often an administrative crutch that is put in place to compensate for staff not being accountable for the ticket queues. Instead, the dispatcher role can simply be a designated role that is shared amongst the Tier 1 staff of the helpdesk. Each day or each week a person is designated as the dispatcher and they are responsible for ensuring that tickets get managed according to the expectations of the users and the IT provider. The dispatcher role as a shared responsibility does two things:

1. Helps everyone respect the role a little more

When a single person is a dispatcher, especially a non-technical person, the techs have a habit of not respecting the direction of the dispatcher. This is cultural and can be changed, but it’s a persistent hurdle for implementing this role. If everyone does this role from time to time, they are likely to respect the direction of others that they view as peers, especially if they are going to be asking for similar things on a different day.

2. Avoids administrative waste

Why have a non-technical dispatcher that can’t pitch in and help the team with tickets when it gets busy? A pure dispatcher role is a consideration when the scale of the team is so large that it becomes a full-time role. Properly structuring your tiers and distributing the dispatcher role within the technical team is far more cost-effective. Even if you have a team of 20 people, this still works.

Dispatch Board

The first two boards that I build for my clients in BrightGauge are the service manager board and the dispatch board. The dispatch board is a fantastic way for the person doing dispatch to have a 500-foot view of the ticket queue. The dashboard helps the person see the exceptions and can act quickly on those exceptions. Managing by exception is a key methodology for working with a high volume of information. Asking a person to know the status and juggle 100 tickets a day is a recipe for burnout. Humans are good at keeping 5-8 points of information in their heads.

Here is an example of a dispatch board.

There is a rule in the LEAN methodology that dashboards should follow the five-second rule. Meaning you should be able to glance at the dashboard and be able to understand it in five seconds. Less is more with dashboards. A great way to make the dashboards more readable in BrightGauge is to use size and color-coding. You’ll notice in the example dashboard graphic above the numbers on the left are black. This indicates that they are informational. The colored gauges moving to the right are coded to indicate the severity of their compliance with expectations. In this example dispatch board we have 6 gauges that are color-coded to manage the ticket queue and service the client experience.

Unassigned/New

Industry best in class response time to new tickets is 15 minutes, but 30 minutes is acceptable if you’re just getting started. Therefore, this number needs to be either 0 or 1. When the number is 0 the gauge is green. Once there is a new ticket, someone needs to respond immediately to acknowledge the ticket and set an expectation with the user of when that ticket will be scheduled. To be very clear, acknowledgment is NOT the autoresponder from the PSA. It is contact either via email or phone from a tier 1 resource or the dispatcher. Actioning the tickets immediately when they come in should help ensure the acknowledgment time stays under 30 minutes and users are given clear expectations about when they will get support.

In the restaurant experience imagine this as how long it takes for you to wait at the door before you’re greeted. Nicer restaurants will have a greeter there all the time welcoming guests and setting expectations for when they will be seated. Even in a standard restaurant where you seat yourself, if a server doesn’t come by to welcome you and get you a water within 20 minutes, you would justifiably be annoyed with the experience.

Stale

A stale ticket means that it has not been touched for more than 3 days. The importance of this gauge is to ensure that there are no tickets left behind. Like the unassigned gauge, stale should be kept to zero. No tickets should go stale if they are assigned to a technician's queue. They should have a routine of touching each ticket every few days to reset expectations with the user about what is being done to resolve the issue. Nothing drives people crazier than to have their support ticket disappear into a black hole. If the technician is waiting on the user, they should be following up via email and phone calls to try to contact the user. This process can largely be automated by your PSA as well to take the load off the tech. If the tech is waiting for a 3rd party vendor or someone else, they should still be updating the user about what they are doing to progress the ticket to resolution. You can buy a lot of grace by just setting and resetting expectations. In the restaurant analogy, this would be how many times the server comes back to your table to see if you need anything while waiting for your meal. If the plates are delayed it’s much nicer to have someone come by and say, “So sorry, I realize you’ve been waiting a while. I just checked with the kitchen and I should have your plates out to you in 10 minutes.” Without this simple polite update, you may grow annoyed that you’ve waited over 30 minutes and not even seen the server.

Past Due

The past-due gauge indicates a technician was scheduled to work on a ticket and that schedule has not been updated. This either happens because they didn’t enter time on the ticket or they didn’t do the scheduled work at all. Like Unassigned and Stale, this number should be kept at zero and will be green when it is zero, but will change color to indicate it requires attention when the number starts to click higher and turn red. Tech scheduling and time entry is much easier to keep under control when done hour by hour. If you get to the end of the week to try and manage time entry and scheduling, you’re always going to be chasing your tail. The dispatcher role can assist the team by at least informing the user that the scheduling of their support has been pushed. This is not something you can do frequently as the person will grow more frustrated by the ticket being delayed, but communicating with them and setting expectations is better than them expecting to hear from someone at 11 am, and getting angry when they don’t hear from someone the rest of the day. The dispatcher can support the team by ensuring they reschedule their tickets and manage their time entry. This helps to re-enforce the growth of this habit over time. It’s IT, it gets busy, so having someone ping you on IM or tap you on the shoulder to ask you to reschedule your tickets helps drive individual accountability.

SLAs

The above metrics are important to ensure the tickets are moved into the service queue and kept current, so they can be resolved as soon as possible. These would be lead indicators. When they turn red you are more likely to fail on the associated lag indicators. SLA compliance is a lag indicator. If you manage the team accountability and the process is followed your lag indicators should be green. I have a detailed blog on SLA management on my website that you can see here.

Average Time to resolution

The average time to resolution indicates how long it took for the ticket to be resolved. This is not the elapsed time, but the SLA work time to complete the ticket. This should be under 8hrs and the lower the better. It’s important that techs don’t game this number by using statuses that park the ticket and turn off the SLA. The client experience is the goal. Not the number itself.

Average Time to Acknowledgement

This gauge is the lag indicator for the new/unassigned gauge. If someone is responsible for the acknowledgment and dispatching of tickets at all times, this SLA is extremely easy to achieve. The one caution here is to train the techs not to try and hero their way through tickets, especially if they are currently holding the dispatch role. If it’s a 5-minute fix, sure do it, but otherwise, queue up the tickets and answer the next call/email.

Not Started

This gauge indicates tickets that have not been started after being put into someone’s queue. Notice this number is yellow despite being quite high relative to the thresholds of the other gauges. The size is also smaller than the other gauges, which communicates its importance. In this case, it’s not necessarily a problem that these many tickets haven’t been started. The thresholds on this number will depend a lot on how many techs you have available to service the support queue. The gauge gives the dispatcher an indication if work is piling up and not moving through the Helpdesk. The number may ebb and flow, but if it steadily climbs, it would indicate to the dispatcher or service manager that someone is stuck on tickets and probably taking too long on a single ticket. This can be great for catching complex support issues before they get out of control. An escalation or a second set of eyes may be helpful.

Arming Dispatch With The Right Data

“Business, like life, is all about how you make people feel. It’s that simple, and it’s that hard.” - Danny Myer, famous restaurateur.

A well-configured BrightGauge dispatch dashboard can support the person responsible for dispatch management to focus on the right things: Managing by exception, keeping support requests flowing, and ensuring users are being kept up to date on the status of their support requests.

Danny Myer’s quote underlines the importance of any service based industry. Make no mistake IT support is a service industry. How the client feels about their support is equally if not more important than the actual service provided.

The experience the users receive is key to creating a sense of value for the support they are receiving. They expect you to be smart and to be able to fix the issues, but actively managing the experience they receive during that support request is what will set you apart from other providers. BrightGauge dashboards are a much easier way to provide an overview of the key metrics required to deliver a high-end support experience for your clients.