Work Culture Improvement and the Little Best Measure of Service Desk Health

I wrote an article for ITSM.tools almost two years ago called IT support: improve where it matters the most. It discussed the challenge of reliability and set-out common support service issues (all 21 issues can be read here), and the fact that one of the primary symptoms of the issues – that end-users “chase” escalations – tend not to be managed well, despite their vital importance. The article probably wasn’t as helpful as it could have been. It only really reinforced what service managers and their teams know – that busy IT support is fraught with difficulties and challenges. This article, therefore, provides some redress by looking more closely at end-user escalation management and why the practice should be integrated into our tool-based incident and request management processes. Not only because it will benefit work culture and customer experience but also for its useful metrics, including an ideal support service key performance indicator (KPI) or what I call the Little Best Measure of Service Desk Health.

This article looks at end-user escalation management and why the practice should be integrated into our tool-based incident and request management processes. #ITSM #ServiceDesk Click To Tweet

An example of why process and work culture are directly related

I recently made the following comment in a chat online about IT support: “I’d add that tools can in fact largely provide the answer to the problem of ABC.” That is, desirable attitudes, behavior, and work culture (ABC) can be acquired naturally in how IT service management (ITSM) tools are used.

The chat was with one of ITIL’s contributors, who replied, “I’m very curious… as that doesn’t match my experience… I’ve seen tools reinforce or degrade behavior (from enforcing process compliance).”

If I interpreted their reply correctly, end-user escalation handling is a good example of what we’re both referring to.

In summary, our standard tool-based “big process” for incident and request management practices provides only very broad, high-level guidance. It doesn’t cover all day-to-day situations, with end-users “chasing” escalations being one. Devoid of an end-user escalation subprocess, teams don’t know how to handle them and would be forgiven for thinking that they’re not particularly important to support service provision because ticket prioritization, i.e., waiting your turn, is the established process and the trump card that takes precedence (including in measuring service desk health).

Standard tool-based 'big process' for incident & request management practices provides only very broad, high-level guidance. It doesn't cover all day-to-day situations… This article explains #ITSM #ServiceDesk Click To Tweet

I’ve worked with senior managers who had the “they must wait their turn” attitude, and I’m sure it’s quite widespread as a default stance.

However, end-user escalations are extremely important

The reason is that ticket prioritization is often inappropriate to actual recipient needs, and few people would make the effort to chase a response unless they really needed it.

Sure, organizations might have a few people who break this presumption to a small degree, but would you chase a response unless you really needed to? Probably not, so by and large, a chase escalation adjusts shortcomings in ticket prioritization, including the tendency for service tickets to dwindle if not completed straight away “on first touch,” because the mid-lifecycle of a ticket is largely unguided.

When a chase is unhandled, or not handled well, customer experience, which is already on the edge, will usually plummet, often causing the horrific “multi-chase” and a complaint. You simply can’t ignore a customer, especially if they have a need that is strong enough to force the service desk to be chased, but unfortunately, process omission can form an attitude and behavior that results in it.

It reminds me of the saying:

“If you can’t describe what you’re doing as a process, you don’t know what you’re doing”

(W. Edwards Deming, who is credited for the Deming Cycle of improvement).

Perhaps Deming should have added, “… so you might do the wrong thing, and processes that do exist can lead you to it.” Paradoxically, it might be better if we were without a basic process if situation-specific subprocesses are not established.

Customer service ticket/case handling process voids can harm work culture and customer experience too.

The alternative to tool-based process – good governance – is tough

Governance and substantial managerial effort are the IT service management (ITSM) way to deal with tool-guided process shortcomings. For incident and request management alone, there are many shortcomings – the 21 common support service issues. That’s tough.

“Nurtured ABC” will always require considerable ongoing commitment and is understandably not prevalent. Undoubtedly, tool-guided process to reliably bring focus – the right focus – when it is needed is preferable.

So, why do we have big voids like this in our big process (and service desk health measurement)?

It’s an interesting question. Moreover, to ponder the enormity of adverse effects that the gaps must have on customer experiences worldwide.

Reasons will vary, but for an end-user escalation subprocess that ITSM tool vendors might provide, subjectivity is perhaps the likely explanation.

The ITIL framework does include consideration of end-user escalations, but despite a process to handle them being fairly easy to design and implement, ITSM tool vendors (who are always ITIL aligned) do not include one.

If we consider that an organization’s approach to handling chased tickets might vary, it’s perhaps not surprising that tool vendors have not bundled it in. Maybe it’s thought that standardization of the approach just isn’t appropriate.

'There is so much value to be released by filling gaps in our standard work management process.' Read this article to understand why. #ITSM #ServiceDesk Click To Tweet

But is it subjective, really? Sure, there might be small differences in approach from one organization to another, for instance, in how long to allow before a response from the ticket owner must be provided, but variation can be encapsulated in how an end-user escalation subprocess is made available as an optional ITSM tool feature, disabled by default.

This makes me wonder whether a secondary possible reason is more at play, that the ITIL processes (practices, if you prefer) as implemented by vendors in their software products, with guidance typically provided by the PinkVERIFY scheme, have simply continued to be accepted as best practice, unchallenged for decades. So, the status quo remains, and teams continue to struggle along.

There’s huge service desk health value to be gained from filling process/practice gaps

There is so much value to be released by filling gaps in our standard work management process. IT support is complex. Only by filling the gaps will teams be able to manage the complexity and so deliver attentive support ordinarily, almost without exception.

As important as it is, the missing end-user escalation process is minor compared to the big gaps. What teams need the most is to get beyond “ticket prioritization,” into activity prioritization, and a way to accurately set expectations so that backlog is prevented and end-user escalations rarely happen.

Teams also need a way of working that requires and ingrains continuous teamwork, in part by moving away from working in ticket ownership silos, which are highly inefficient and vulnerable. A fourth primary need is for accurate and detailed time-based metrics that enable informed decisions on where to steer service delivery back in the right direction.

Thankfully, all these things are not difficult for organizations to achieve, nor for tool vendors to provide. Continuous teamwork can come from introducing a practice of activity prioritization. In more adaptable service management tools, detailed service insight that includes accurate expectations management can be bolted on without much development.

But perhaps start with an end-user escalation subprocess

Even for teams who adopt a practice of activity prioritization, particularly if the practice is not fully developed, chase escalations might still happen. When they do, teams should be enabled to make the right decision, overseen “at a glance” by managers. Having this capability can only be good for work culture.

Unlike a practice of activity prioritization, functionality for a complete end-user escalation process needs to be added by tool vendors, however, unless you use what might be called an IT Business Process Management (BPM) tool.

The difference between ITIL workflow and IT BPM tools

Customers cannot configure it in most tools because most are ITIL workflow tools that don’t have open extensibility. Tools with open extensibility – for instance, ServiceNow and Cherwell Service Management – are business process management (BPM) tools for the ITSM market. Process platforms that allow custom tables, forms, buttons, and other objects to be added with advanced custom event procedures that can run against any database or front-end object so that add-ons, or entire self-contained applications, can be created.

There is a way for customers to customize ITIL workflow tools to introduce a basic end-user escalation subprocess that reliably identifies all chase events, including those raised by ticket updates on a service portal. Still, it’s without a few important outcome benefits. This will usually include information that enables managerial coordination and measurability of service desk health.

The little best measure of service desk health

Beyond improving reliability in meeting service recipient needs and expectations, organizations will benefit from having an end-user escalation management process because the frequency of tickets being chased might reflect support service health better than any other measure. Albeit only at the extreme edge of customer experience where recipients are compelled to chase.

With a service desk’s ability to meet needs and expectations measured and therefore known for the first time, an improvement objective and service desk KPI would be diminishing numbers over time. Low or even zero incidences continuously over many months is probably the most pleasing sign of healthy service that there can be.

To further boost accountability, mean-time to escalation response might also be measured and reported. An important thing to recognize is that measuring subprocess performance focuses minds on positive outcomes, forming a “virtuous circle” of benefit, in this example, quick escalation response. The same is unlikely to be true of a broad parent process such as incident and service request management.

ITIL 4 Explained

What is ITIL?

Which ITSM Tool? Here’s an ITSM Tools List

Enterprise Service Management Explained

What ITSM Pros Need to Know About CMDBs

How to Define, Measure, and Report IT Service Availability