For IT support improvement, ticket progression issues should be tackled first. But why start with ticket progression issues? It’s because industry benchmark metrics confirm that most negative service experiences are due to slowness and tickets not being completed at all – service failure. But what causes slow and failed service? This article explains the three specific causes and how to fix them. In a nutshell, ticket prioritization isn’t adequate, but activity prioritization is.
Most negative service experiences are due to slowness and service failure. But what causes slow & failed service? This article explains the three specific causes and how to fix them. #ITSupport #ITSM #ServiceDesk Click To TweetThe IT support improvement fix
First, those who struggle to keep their ticket queue healthy must become more attentive to what’s required for good support. Second, better teamwork is needed to dissolve ticket silos.
“Be attentive” is the first of twenty high-performance principles covered by a new way of working I have been developing for IT support improvement, called the focus framework, or TOFT. TOFT principles can be learned and nurtured or embedded through tool-based practices that supplement those provided as standard by IT service management (ITSM) tool vendors, continually guiding teams to be as effective as possible.
Of twelve “infill” practices, activity prioritization will always make the most significant difference. In its form that incorporates motivated cross-queue-cover (there is no doubt that people are keen to go “above and beyond” when recognized for doing so), if you had no knowledge silos and never any staff shortages, unmanaged backlog and chased tickets would become things of the past, almost entirely. That’s unrealistic, but activity prioritization promises to ensure these ever-present symptoms of weak service delivery remain very slight, with timely ticket progression happening with only rare exceptions.
'Those who struggle to keep their ticket queue healthy must become more attentive to what’s required for good support.' This article explains. #ITSupport #ITSM #ServiceDesk Click To TweetActivity prioritization is an IT support improvement fix-all in several areas, including that its information satisfies the other main requirement for ideal support – palatable, accurate expectations management.
The three fixed issues
One of the biggest operational issues for IT support is something that an IT organization might not fully recognize. Support team members often do not manage requester updates well. Whether an update is by email or through a service portal, when not seen or acted upon promptly, the requester is left ignored. This shortcoming is inevitable when staff are on leave and for unassigned tickets.
When an update enables onward progression, the least that should be done is acknowledging the update’s review and reconfirming expectations promptly. You won’t be doing this unless your organization is good at support. Instead, if an update is wholly ignored in that it does not trigger any progression, the requester might chase a response.
I’ve mentioned requesters being ignored in previous articles in the context of chased tickets. Many tickets are chased by way of a ticket update, so the two scenarios in which requesters are ignored are, to a large extent, the same issue. The horrific multi-chase sometimes results because the requester continues to be ignored, and this is no doubt where reputational harm is at its worst.
Even if a requester update is simply to confirm ticket completion, ignoring it exposes the service provider as disorganized. Open tickets are visible on the portal, and an untimely closure email might eventually be received. It’s another thing to dent IT’s reputation. When a requester is ignored, it is the opposite of support and service. Absent activity prioritization is the cause.
One of the biggest operational issues for IT support is something that an IT organization might not fully recognize… Take a look here to find out. #ITSupport #ITSM #ServiceDesk Click To TweetInadequate prioritization causes two other operational issues in which requesters are also ignored. When information that a requester has been asked for is not automatically chased by an ITSM tool automation process, it is left for teams to chase a response. Tickets at the “with user” status, however, naturally sit at the bottom priority rung because the service level agreement (SLA) timer is stopped and “the ball is in the other court.” The need, and therefore the requester, is (again) ignored. It is no doubt a primary cause of service failure.
The third IT support improvement issue is perhaps the worst, heightened by the other two issues. Busy teams naturally focus mainly on “the here and now” of new tickets and other competing work demands because ticket prioritization provides no guidance between a first response and the service level target breach warning, and for the same reasons that requester updates are often ignored, breach warnings and the breach are very often inadequately managed.
As a result, and compounded by the fact that most aging tickets are usually placed on hold to stop the SLA timer, older tickets tend to dwindle, forming large swathes of unmanaged backlog.
In my experience, this phenomenon typically more than doubles open-ticket volume compared to what it should be before a governance-steered ticket purge becomes necessary. If just one thing were needed to tell us that something is wrong with standard practice, it is that.
Why is it this way?
Why does it take an experience management practice to hopefully bring an IT organization’s attention to these major issues and IT support improvement opportunites? I am sure the answer is that ITIL standard practice that we are provided with for use in our ITSM tool is accepted as being best practice that teams can run with to work as well as possible.
Practice gaps and the need for activity prioritization aside, IT organizations do not realize a standard operating procedure (SOP) of “this is how we do IT support” is needed to consolidate the use of ITSM tool processes and features for teams to follow.
Without an SOP, the status quo is simply tolerated as “it is what it is,” and teams continue to muddle along.
Start where you are (with IT support improvement)…
As a start, support team managers and governance alike need to acknowledge the operational issues and that something needs to be done about them, whether that’s experience management, an SOP, activity prioritization, or, ideally, all three.
It should be recognized that it is not enough to expect team members to proactively respond to ticket event notifications, especially as it is common for team members to filter them out of their inboxes because they cause excessive email noise. This is a good reason to go digital in how you work.
Nor can it be expected that teams will proactively manage their activity in a digital way around corresponding flags in their ITSM tool. By default, there simply is no process or procedure to indoctrinate it.
Progression point prioritization is a basic form of activity prioritization that can be introduced in any ITSM tool, says David Stewart. Here he explains more. #ITSM #ServiceDesk #ITSupport Click To TweetIf your support teams do have an SOP, you have made a good start, but are ticket event “progression points” included to align team behavior, and do you ensure the SOP is learned? Only when you get to this point, ideally formalized with a dashboard-led practice for “progression point prioritization,” will service provision become more attentive.
Progression point prioritization is a basic form of activity prioritization that can be introduced in any ITSM tool. It is a transition between the two approaches for bridging standard practice gaps as set out in TOFT, from learned and nurtured, into the realm of tool-based “infill” practices.
The optimal approach to IT support improvement
Advanced activity prioritization is based on continually using a complete set of meaningful ticket lifecycle statuses. ITSM tool customers can introduce it in a few tools that meet a particular functional requirement.
A few years ago, during several employments, I mapped out all common ticket lifecycle scenarios and their corresponding meaningful statuses, plus others relevant to some IT organizations. When they are introduced to improve how teams approach their work, whenever a service ticket is progressed or updated, its status can – and should – be changed to reflect what needs to happen next.
Most support organizations use some non-standard statuses (albeit loosely), so working this way is a simple adjustment. It is worthwhile if only because it clarifies the situation of all open tickets. More crucially, though, in the few tools that support it, each status can be given an appropriate progression threshold period that is used by the tool to calculate a progression threshold timestamp each time a ticket’s status is changed.
To achieve timeliness, team members must adhere to status management and approach workload according to the sequence of dynamically updated progression threshold timestamps, aiming to avoid progression breaches.
As far as operating procedures go, it couldn’t be simpler, and with a bit more adjustment in how teams work, motivated collective teamwork can become the norm to provide cover when queues fall behind.
Ultimately, support’s biggest constraint – ticket ownership silos – can be removed for some teams, particularly for an IT service desk, if it benefits from a high proportion of tickets raised through a service portal, replaced with multiplied ticket cover through role-based status queue ownership. Timeliness then becomes owned, not tickets, and jointly, no longer in silos.
More on the subject of IT support improvement…
Activity prioritization is explained and illustrated on Opimise.com, and the twenty high-performance principles are covered in a free course.
Further Reading
If you enjoyed this IT support improvement article, then here are some other articles you may find useful:
David Stewart
David is a consultant who works with organisations in their adoption of TOFT practices.
