Here's Why You Treat End-User Escalations Seriously

Why are chased tickets important?

A “valid” chase is an extreme event in a ticket’s lifecycle. A requester makes the effort to chase because the service provider has not met their pressing needs, and palatable expectations have not been set to avoid the chase, or expectations for a pressing need were set but not met.

All chases need proper consideration

A support team’s purpose is to meet needs and expectations, so all chases should be carefully considered for validity. For routine tasks that have a standard approach or are straight-forward to complete, I would suggest that a chase be considered valid when:

1. The need is truly urgent, but irrespective of the response service level target, the resolver team has taken too long for their initial response. This can happen when a service ticket is not prioritized well or did not reach the resolver team straight-away.
2. A relatively urgent need is not met at the initial response, an adequate workaround has not been provided and the wait for follow-on activity has been too long. A ticket’s completion target might be inappropriate for a relatively urgent need, so this should probably not be used to decide validity.
3. The need was not initially urgent, but the service level target has been missed and an adequate workaround has not been provided. The chase becomes increasingly valid the longer the completion target has been in breach. The important perspective here is that because the requester is making the effort to chase, the need is likely to be relatively urgent amongst others that have breached their target, even if the fact might not seem obvious to the support team.

For non-routine tasks, in addition to 1 and 2:

1. The final resolver team has provided an initial response, an adequate workaround has not been provided and expectations have not been adequately communicated around a routine approach being unavailable, and to make clear that the route to resolution is complicated, necessitating a long lead time. In this situation, the resolver team should at least use the chase as a trigger to communicate these facts, to set expectations.
2. The support case previously had expectations set but did not progress in line with expectations.

Whether or not a chase is initially thought to be valid, it should always be properly discussed with the requester, to see things from their perspective. This is an important skill for all support teams to develop because balanced, empathetic decisions made alongside consideration of journalled ticket history, will mean not only that requesters are not ignored, but also that the service desk does not unduly chase ticket owners.

Invalid chases must wait

If invalidly chased tickets are prioritized ahead of others, a user base might tend to chase as a default approach, to avoid waiting. So, it is important that support teams get the balance right.

Escalations handled well infuse operational advantage

In an ideal world, there would be little need for end-users to chase a response. Unfortunately, though, ticket-based prioritization does not prevent it sometimes being necessary to move things along. So, in larger IT organizations, chases do happen often. There is a bright side though. Chases effectively serve to adjust shortcomings in ticket-based prioritization, and expectations management too. Failure to see things this way and to do the right things to address them will of course cause operational disadvantage where frustration with IT support is made not better, but worse.

Without a good chase process, the service outcome is not good

Whatever the work situation might be, in my view, if there is not a good process to handle it, unless the required approach is common sense, teammates will default to the view that the situation is not important and so might do nothing about it, or perhaps even worse, will do the wrong thing.

There is the old saying that if you can’t describe what you are doing in terms of a process, you don’t know what you are doing. If you don’t know what you are doing, there is little point in doing anything. This might go some way to explaining why levels of engagement in the workplace are known from research to be shockingly low.

To address the natural tendency towards apathy when there is no process providing guidance, with there being so many operational process gaps in IT, there is a movement behind “humanizing IT”. That is, to empathize with stakeholders; to “be attentive” to their needs and expectations. This nurtured approach to improving attitudes and resulting behaviors for better outcomes is great, but in many situations, help is needed from a good process to steer when it is necessary for decisions to be closely considered from the perspective of stakeholders.

Without a good process for chase management, teams only have the broad sweep of ticket-based prioritization, so unless a chase “kicks off” as a complaint, the natural and commonly held view is one of “they need to wait their turn”, even if that doesn’t feel right. Unfortunately, in my experience, this view is also held by many managers too, not appreciating that ticket-based prioritization has many shortcomings that make it inadequate as guidance in many situations.

So, unless a chaser makes a fuss, our natural tendency is to simply update the ticket to reflect that an update has been requested. Without rationalizing the chase by discussing it properly with the requester, this is not helpful at all, especially because ticket updates are often not seen by ticket owners or are not seen for a long time.

From the requester’s perspective, to be ignored is never good, especially when a need is truly urgent. To be continually ignored makes things worse and worse. I have seen tickets chased more than half a dozen times before the requester was eventually contacted. Imagine the frustration and negative perception of service, but in absence of a good process, who would know?

SO, what is required for a good chase management process?

To introduce a good chase process, several challenges must be overcome.

Firstly, IT organizations must recognize the need. Knowledge of its extent and severity is difficult to gain though because there is no process to bring-about measurement, and most chases are hidden in ticket updates.

Secondly, as far as I’m aware, no ITSM tool has a chase management feature, so individual organizations must plug the process gap themselves.

The third challenge is that a good process necessitates having a dedicated chase module. In other words, a service tool must be extended, not simply configured. Most tools are not flexible enough for a good process to be introduced.

A fourth challenge is that the process must include a means to chase through the service portal and then of course, unless the support service is able to reliably meet needs and expectations, some requesters will inevitably abuse the process by continually submitting invalid chases, so it will probably be necessary to have a feature that disables the portal option for individuals who do, forcing their chases to be channeled through a phone call, to be rationalized by the service desk instead. So, the ability to reliably meet needs and expectations might need to come first.

Lastly, some will be appointment requests, including notifications of “I am available now”. These are not chases but are important ticket lifecycle events all-the-same, needing to be handled through a separate ticket management sub-process, excluding them from chase management and measurement.

Relevance for experience management (ITXM)

In my view, chases are the best barometer of support service health, of a provider’s ability to meet needs and expectations, and I wonder what impact properly managing them would have on service experience scores, even if support's general ability to reliably meet needs and expectations is not improved.

A good process will measure the proportional up or down trend in validly chased tickets, how quickly chases are progressed, and the proportion that become a multi-chase. These events are service outcomes strongly related to service experience.

To measure chases has advantages over the post-ticket survey approach for gauging support service health. The important differences compared to ITXM data are that firstly, a valid chase is operational information confirming that delivery failed at the point it happened, before it is too late to make amends. Secondly, the situation is known to have been urgent and important to the service recipient because they made the effort to chase.

With experience management data, feedback of support having been unacceptably slow is too late to make amends and does not confirm that the requester needed support to be provided faster, although a good experience management practice will provide some insight into this detail by asking for a requester’s estimate of lost work time.

Overall, it seems to me that measured user escalations would be ideal for inclusion in an overall experience level agreement (XLA), if you have one, and in a ticket SLA, too. In fact, chase management, if it were ever to become a practice provided by ITSM tool vendors, is a practice that would begin to align the SLA with the XLA much more closely together.