IT Ticket Lifecycle Superpowers

How you label your tickets can determine what tickets remain in limbo. Here is a way to analyze your ticket labeling process.

When you get to know and make best use of the real ticket lifecycle, all common things that harm IT support can be fixed, including responsiveness and reliability.

SIMPLY ADJUST YOUR APPROACH

To make best use of the ticket lifecycle, whether it be the basic ITIL approach that we all know, or the real ticket lifecycle, it must be thought of as a series of progression points for teams to follow so that the most appropriate direction is taken from one activity to the next.

START WHERE YOU ARE

The easiest place to start is to present ITIL’s progression points, plus at least one other that’s frequently present in the lifecycle and is crucial for timeliness.

ITIL’s progression points are:

• Ticket assignment
• First-response warning
• Completion service level target (SLT) warning
• SLT breach

The other essential progression point is ticket updates made by a requester or colleague. Despite being missing from the standard ITIL approach, ITSM tools often include it out-of-the-box, or it can be incorporated with a little configuration, so it might be added to a progression dashboard as easily as the others.

If these five progression points do not form a progression dashboard, or a team’s standard operating procedure is not to follow it, responsiveness around these events will very often be missing.

They are a good starting point for the 4 Ps of performance. They are:

• Progression point prioritization (PPP)
• Presentation (on a progression dashboard)

Then, for the approach to really take off:

• Performance-pull (through a practice of contribution recognition).
• Pulling-together (teamwork)

PPP is activity prioritization. When applied to the standard ticket lifecycle, the ITIL approach works effectively.

In its more advanced form, PPP integrates non-standard ticket statuses that make up the real ticket lifecycle. Individual statuses or groups of statuses form additional progression points for prioritization through a progression dashboard.

For example, an IT organization might choose “action required” as the status that’s set when a ticket receives an update from a requester or a colleague. This progression point would be given a relatively high level of presented priority, particularly because the update might be a chase escalation, and because the SLT timer will ordinarily no longer be on-hold.

Working wholly by lifecycle statuses brings breakthrough capabilities.

WITHOUT PPP, PROGRESSION STALLS INSTEAD (AND SO IT DOES)

Unless progression point prioritization, incorporating custom statuses, becomes the way of working, the opposite of progression tends to happen.

All larger organizations adopt custom statuses. Custom statuses usually place a ticket “on hold”. The SLT will not breach, so prioritization of the ticket is naturally demoted to the bottom rung. In busy teams, the ticket tends to stall and so is particularly prone to abandonment and service failure.

IT organizations do not do activity prioritization (PPP). Basic ticket prioritization has always been the standard approach. So, frequent ticket abandonment and service failure is the reality, the world over.

FILL THE GAPS

The in-progress and on-hold stages of the ITIL lifecycle are where most custom statuses of the real ticket lifecycle are added.

IT organizations rarely identify all statuses across all support scenarios though. The real ticket lifecycle is not adopted, let alone used for activity prioritization.

A lifecycle status should be concise and provide snapshot visibility into what needs to happen next, for instance “with user” or “with colleague”, but statuses that organizations adopt tend to be added “piecemeal”. There is no end-to-end process for their use.

SO, THIS IS WHAT WE HAVE INSTEAD...

In my opinion, tool vendors should provide an ITIL-based progression dashboard template to build upon, to enable IT organizations to work effectively. They don’t though, so the reality is what we all know and accept to be the status quo.

Ticket progression and completion is unreliable, backlog growth is uncontrolled, and so chase escalations are frequent.

Plain and simple, our standard approach, as provided by tool vendors, is inadequate. I can but try and hope to change that.

NEXT

Still on the subject and support principle of “be attentive”, status prioritization will be the subject of my next two articles, including why a practice of “contribution recognition” is necessary and is the catalyst often required for the real ticket lifecycle to gain traction, for all the many benefits that result.