Support expectations rely largely on completion targets, but this is not their purpose. How can we improve this situation?
by
David Stewart
Date Published November 13, 2023 - Last Updated December 5, 2023
Support expectations rely largely on completion targets, but being primarily for gauging performance, this is neither their purpose, nor what they are suited for.
For example, if a completion target is a day away but the need is a password reset that will be done quickly at initial response or probably well before, the timeframe is inappropriate and unhelpful.
Or, if a medium priority ticket is for a need that will take weeks or more, again, the target is misleading and unhelpful. The requester must at least be informed of the reason for it taking longer, otherwise they will rightly feel ignored, and a chase might be the outcome.
In this article, I will explain what can be done to improve the situation.
First, let’s delve into why expectations management is important and needs improvement.
Why does expectations management need improvement?
No matter how much automation, AI, and so on are introduced, it will always be that a large proportion of service tickets are not completed quickly. If expectations are not set to put minds at rest, or are inappropriate and unpalatable, users might be inclined to chase a response as much as when expectations that have been set, are not met.
So, it is important to meet expectations as well as needs, but larger IT organizations usually receive numerous chases by phone every day, plus many more that are hidden in ticket updates, confirming that expectations are not being managed well.
The main thing to understand on the topic though, is why some needs take a long time to be met, extending well beyond a completion target, and why expectations might not be managed well for ageing tickets.
Why are aging tickets IT support’s Archilles heel?
The full answer is perhaps not what you might think.
The obvious reason is that some teams are just too busy. Especially considering needs are sometimes complicated, or unprecedented, more people would be needed to speed things up across the board.
Of course, speed of delivery is directly related to team size, but it is also related to operational efficiency that comes from the overall approach that a team follows, of focused roles, processes, practices, procedures, and perhaps most important of all, teamwork in helping one another, and helping-out with one-another’s ticket queues.
The need for operational improvements is not lost on many holding the purse strings. For someone who covers support all day long, if their volume of ticketed activity isn’t good, and if ticket queues sometimes fall out of control, it points to operational deficiencies that should be identified and overcome rather than bring more people into a team.
In earlier articles, I covered the challenge in finding a way to improve how workload is managed. With 27 operational inputs, and dozens of ticket lifecycle situations (statuses) that can come into play, all of which must be balanced and checked, IT support is complex, but ticket-based prioritization is a basic process that usually has workload split not only across many vulnerable and inefficient ticket queue silos, but also split simply into new and ageing (in-progress or on-hold) ticket statuses.
Aging tickets naturally play second fiddle to the “here and now” of new tickets and other pressing things, making it impossible, without an improved approach, to know when progress will happen, let alone completion.
Ticket-based prioritization is far from being able to guide teams through the complexity or enable good expectations management. So, a reluctant budget stretch might be considered the only option.
Good prioritization, where ageing tickets are prioritized alongside new ones, and good expectations management that can arise from it, are the “yin and yang” of excellent IT support. Together, requesters will rarely have reason to chase a response. In my view, an IT organization’s strategy should have their intertwined objectives front-and-center. But first, it might be necessary for governance to realize two things.
The first is that a completion target is a deadline that should be avoided if possible. It is not for guiding progression, and it is not suited to expectations management either.
The second is that when teams find time to look at ageing tickets, the natural tendency is to “cherry pick” quick fixes to get tickets closed off, not to organize by completion target and work backwards in that order once requester updates have been reviewed and answered, which is the best approach that can be reached with ticket-based prioritization.
This is important for ITSM. If you take just one thing from my articles, it should be this. Ticket-based prioritization works well only for the initial response. It does not work well (or at all) for tickets that need more involvement. Indeed, it was, I am sure, not intended to.
The shortcoming means that an IT organization’s usual approach is to allow tickets to be placed into on-hold limbo. Doing so renders the completion target null and void, so unless a reason is communicated when on-hold is used, any semblance of expectations management is removed with it. Unmanaged on-hold also denigrates a ticket to the bottom rung where it can easily be forgotten, with no negative effect on the SLA.
If your organization does not use on-hold because of the operational issues it causes, it might be that more tickets will breach their completion target and remain that way for long periods because really, tickets do often need to be put on hold for a time.
If your organization does use it, it is important to have a reliable procedure that ensures appropriate use every time. Personally, I have never known an organization that does, so the same situation resides, of tickets often falling into SLA breach and remaining that way for a long time, alongside the difficulties and issues in use of on-hold too.
It is a case of “damned if you do and damned if you don’t,” and even more so if you do but sometimes don’t when you should do. Urgh. it just doesn’t work.
Similar can be said of the main “watermelon” metric, the Resolution SLA, which is a service level expectations metric. Its accuracy, validity, and relevance rely on standardization in appropriate use of on-hold which is ordinarily near impossible to achieve.
Both are interesting paradoxes that have always resided in IT support. You need to use them, but you probably shouldn’t because if you do, you will have substantial operational issues including tickets that take longer to complete, and time-based measurement that is rendered statistically invalid and therefore far more misleading and pointless than any experience management article I’ve read would have you believe.
It might have seemed that talking about IT support’s paradoxes was going off-point, but it all ties into difficulties with expectations management. The overall conclusion is that it's not just expectations management that’s a quandary. It is the whole of how IT support is traditionally done.
Light, at the end of the tunnel
If you have read my earlier articles, you will know that thankfully, there is a simple fix for it all.
Through status management, status-based prioritization guides teams through the complexity of what is often unknown when a ticket is first raised. Precise expectations for progression or completion not only become known, but can usually be met, and being status-based, on-hold periods are closely controlled too, for accurate and valid Resolution SLA measurement, reflecting true service performance and what can be expected.
It cannot be introduced in most ITSM tools though, so are there any other options?
Other ways to improve expectations management:
There are other options, but they're far from ideal.
The first is to establish a dedicated role to cover all aging tickets, across all ticket queues, per team.
A second is to ensure good journaling.
In my last article, I touched on the fact that support staff tend to use private journal notes, but there is imperative to ensure informative public journals are used instead, so that requesters are kept informed of progress.
While you might then expect to see the incidence of chased tickets reduce, and service experience ratings improve, there is little point in progressing a ticket with a good update included if timely follow-on activity is then missing. Good prioritization of work activity is simply the base necessity whether we are wanting to meet needs or expectations.
So, if not designating a role to cover ageing tickets, the only other option is to exert a great deal of costly, onerous daily managerial effort and intervention to manually provide focused guidance for teams, together with updated expectations communicated to requesters. Not surprisingly, it is rare for the prioritization gap to be filled in this way.
Tag(s): supportworld, performance management, support models
Comments: