ITIL & Support Flow Management: Key facts

Lesson 1 of the SOFF Foundation course.

For over three decades, ITIL's dominant best practice stature concealed four pivotal facts and that overall, it made a crucial oversight. ITIL missed something vital out - the process root cause of weak support.

Capabilities for Flow Management fill the gap, fixing timeliness, expectations management, performance, weak metrics, teamwork and more.

The Problem Caused by the Oversight

Most IT support professionaIs meet service targets well enough to satisfy IT standards, but a large proportion of recipients end-up dissatisfied. Fact is, ordinarily, IT's ability to meet needs and expectations is far worse than is known.

Worsening outcomes, recipients learn that if support is chased for a response to something urgent, the effort often goes unnoticed and unaddressed even if the Service Desk process seems good. Consequently, many recipients are inclined not to chase when necessary to do so, letting the support experience slip further still.

By practicing Experience Management (XM), a much clearer picture of the problem's extent is realised. Of tickets not completed at the initial response, over a third are felt to take too long, and a quarter turn bad*.

Detailed analysis of any organisation's ticket backlog confirms why this is the reality, but the cause is not so much in teams being busy. The cause is inadequate prioritisation of an inadequate process.

In ITIL standard practice, tickets are organised only by the initial response deadline, then, for those requiring further work, by ticket age and perceived priority, with the oldest tending to come last.

What is needed, though, is for work to be organised by the continuous activity that's required for attentive service. Formed from new guidance that ITIL missed out, Activity Prioritisation is a breakthrough that does precisely that.

Here's the Key Facts:

With its processes the basis of all ITSM tools, ITIL is firmly "baked-in" to the status quo, making its best practice stature powerful and unquestioned.
But ITIL is a framework, not a methodology.
Framework processes are minimum operational requirements - best practice at the most basic level.
A framework's processes must be built-upon to meet operational needs, but ITSM tools provide ITIL's largely "as is".
For most processes, that's ok, but not for IT support.
ITIL's minimum requirement for IT support is a ticket-focused approach that guides only new ticket responses - nothing afterwards except a deadline for completion. So that is the process found in all tools, used the world over.
Typically, over a quarter of support tickets are not completed at the initial response (30% according to MetricNet), requiring timely onward progression activity before completion is reached.
Effective communication with service customers is key, but with a process that prioritises only tickets, not progression activity, communication could not be weaker.

Note 1: Rather than simply "On-hold" and "In progress", meaningful conversational statuses are used in some organisations, but still, in standard practice without Activity Prioritisation, they do not rise to the top for prioritised attention.

Note 2: It is not enough for teammates to send an email and expect that the service customer will respond. Ticketed communication from IT is an ITSM tool (system) notification. Some recipients filter notifications out in their email software, or simply ignore them. Often, at least some phone or IM based reapproach is necessary.

1: Absence of a way to identify, prioritise, and manage progression activity is a big shortcoming - a critical gap in support's process.
2: Consistent status management brings focus to required activity, enabling timeliness for all ticket situations through Activity Prioritisation (AP). It is a key aspect of support's minimum requirement, but it is absent in ITIL.

Absence in ITIL means absence in tools, forming a status quo in which support is inattentive because it is focused on the wrong thing.

ITIL's crucial oversight is absence of Consistent Status Management in its guidance

Other than "On-hold", just two ticket statuses are provided by ITIL and ITSM tools for the ticket-focused approach - "New" and "In progress".
Many ticket situations sit under the broad scope of "In progress". Each has its own distinct status to identify what needs to happen next, and an appropriate timeframe for when progression should happen.

For example, after an email is sent, a status for follow-up by phone or IM might be "Reattempt contact", and IT governance might decide that the appropriate timeframe is two-hours from when the status is set. For when a customer replies, the status might be "Attention", with teams expected to review tickets that change to this status within 90-minutes.
But in ITIL standard practice with just two generic statuses and ticket-based prioritisation, what needs to happen next is not only unidentified, the required activity continues to drop down towards the bottom of ticket lists where it naturally receives the least attention, especially when "On-hold", leaving service customers frequently ignored. Other than causing weak communication where conversation threads suffer long delays or inertia, it is why ticket backlog is badly managed.
Unidentified ticket progression activity continues to drop to the bottom of ticket lists because with support organised by ticket age, new tickets are usually at the top.
All kinds of ticketed communication are affected.

Worsening outcomes further still, as a framework, supporting processes are also absent in ITIL, including a way to handle chased progression which frequently arises due to untimeliness inherent of ITIL's misfocused approach.

Most chases are nothing more than a buried ticket update - just one kind of ticketed communication that's prone to failure. The result is "multi-chases" that despite being the worst of support outcomes, go unrecognised.

In total, 21 ticket situations - support statuses - are left unmanaged in every IT organisation, all causing inappropriate delays and ticket inertia, primarily:

Those for complicated "cases" that involve many steps before eventual completion;
Support appointments, including where coordinated contact is necessary because a customer's availability is limited;
Supplier provided service.

Making susceptibility to untimely weak support far worse, support teams work in ticket queue silos. Work silos are inefficient, and are vulnerable to inadequate cover when ticket owners are too busy or unavailable to cover support.

3: The critical oversight - that is, absence of consistent status management in ITIL's guidance - has been harmful for another reason that's even more fundamental than inadequate prioritisation.

The accuracy and validity of support's primary metric, the ticket resolution SLA, necessitates consistently appropriate exclusion of "on-hold" periods. Ticket on-hold is mapped to statuses, so controlled on-hold is possible only through consistent status management, plus its use for Activity Prioritisation to ensure on-hold tickets do not stagnate while being protected from breaching their SLA target.

Without it, "uncontrolled on-hold", or an operational decision to disable on-hold functionality because of the issues it causes, means an SLA dataset is always so inaccurate that even with extensive ticket-by-ticket review and dataset editing, SLA reports might still be statistically invalid.

It's a stark fact. Due to ITIL's oversight, ordinarily, support's measure for the performance of its processes is invalid and should not be used.

The Solution and Way Forward

Flow Management's base capability, Activity Prioritisation (explained here), produces time-based metrics that are wholly accurate and meaningful by default, bringing absolute validity to a ticket SLA for the first time, removing the need for data review and editing.

AP fixes the ticket SLA, but mainly it fixes timeliness across all ticket situations so that business lost work time is minimised, SLA breaches are minimised, and precise, dynamic timeframe expectations can be shared.
In standard AP, work is organised by when progression is scheduled to happen instead of by ticket age. New ticket responses are merged with the timely scheduled progression of all older tickets...

Together, fluid ticket-based conversations, handled chases, and good expectations management reverses IT's reputation for weak communication.

But without Flow Management, this is the status-quo:

ITIL's processes for Incident and Request Management are absolutely minimal - too minimal - devoid of capability to handle support's complexity.
Teams are left misfocused, and unfocused, unable to fulfil their purpose of always timely, attentive service provision.

4: Inextricably, without adding Support Flow Management, every ITSM tool, and almost every support service that relies on them worldwide, is not fit for purpose. The reputation of IT support is harmed for little other reason.

ITIL's embedded stature shields recognition of this pivotal fact. Organisations do not realise that support's process is too basic. Instead of looking to improve the process, even if practicing Experience Management to expose and address the extent of weak support outcomes, weak support is considered to be largely unavoidable because ITIL best practice is in use.
Global harm in lost work time, customer frustration, and IT's reputation, is immeasurable.

The breakthrough is to establish at least AP's complete set of twelve meaningful statuses. Only then does consistent status management become possible, for all the many benefits that then arise.

The imperative:

Without Activity Prioritisation, in fighting a weak process, any attempt at improvement cannot get far and usually makes support outcomes worse. Experience Management initiatives are no exception (read more).

Standard Activity Prioritisation (sAP) is a rare kind of process. Despite being incredibly simple, it guides effectiveness with no need for governance and management.

In use of sAP with "pinpoint" expectations management, when communicated progression timeframes are not met, service experience dips. This knowledge is captured in Flow Management's Flow Metrics.
Flow Metrics measure the attentiveness of support, in real-time and retrospectively.
Attentiveness is what's necessary for good service experiences.
For an XLA, key Flow Metrics are:

Progression SLA, for example, "Attentiveness: For tickets not completed at the first response, 80% of scheduled ticket progression will happen on time; 97% within 4-hours of progression thresholds breaching";

Progression Backlog, for example "Progression Backlog will not exceed 5% of open tickets".
By controlling progression backlog, ideally through advanced AP, not only are expectations met as well as possible, ticket backlog is controlled.
By contast, even if the ticket resolution SLA is given a degree of validity through dataset review and editing, still, like the process it measures, it is equally unfocused and unfit for purpose.

Being focused on tickets, not required activity, the metric in no way reflects attentiveness. This fact is a key driver of the Experience Management movement in ITSM and explains why the ticket SLA is not widely used other than in managed services.
ITIL is no longer process oriented. It has moved even further from being suitable as the benchmark for ITSM tool functionality and IT support's way of working.
A detailed methodology was always needed, not a framework of general guidance.
The Flow Management methodology has an entry point for every organisation. Any ITSM tool becomes nearly fit for purpose simply by consistent status management becoming an organisation's way of working, and by switching from unhelpful ticket lists to an organised basic AP Progression Dashboard.

Basic AP makes the ITIL process much more successful by bringing procedural focus to SLA Breach Prevention and conversation threads.

sAP has several advantages over basic AP. Workload is presented through a single ticket list which is the way teams have always worked, adding to its simplicity that makes it easier than any other approach, but all required activity is sequenced with ideal timing:

Most people in IT support realise that status management should be advantageous. Some non-standard statuses are commonly added to ITSM tools. Alignment with the Focus Framework to enable the breakthrough - consistent status management in which it becomes advantageous - is a natural and popular enhancement.

Advanced AP and Perfect Prioritisation combine sAP with a Progression Dashboard and optionally, advanced Flow Management capabilities, to reach a target level of operational maturity and if desired, true optimisation in which ITIL's processes are made as successful as possible.

AP's counterpart, Contribution Recognition, enables advanced AP and Perfect Prioritisation because without effort being recognised, there is no impetus to help-out across ticket queue silos.
Contribution Recognition is based on Flow Management's Activity Flow Metrics which are the all-inclusive, accurate and fair representation of a teammate's contribution at work. The Contribution Recognition standard includes mechanisms to ensure accurate fair representation.

Gallup Inc. research shows that when teammates are given performance information of this quality, engagement more than doubles.

Unless provided natively as standard in ITSM tools, sAP and Contribution Recognition can be added only to highly flexible tools. The Focus Framework goal is for all tools to introduce both key capabilities as standard.
Opimise own, manage and maintain the Focus Framework, including a list of compatible tools. Compatibility is identified by which capabilities are available as standard, as an add-on, or as features that can be developed by individual organisations themselves.
Activity Prioritisation of any type enables Portal Purposing for the Digital Channel Service Desk.

As a methodology and standard for modern people-provided support, the many vital but generally unrecognised reasons for moving away from old-fashioned call-centre reliance form a core aspect of the Focus Framework, alongside the solution that transforms a service portal into the number 1 choice for all support needs - something that is more important than ever with the advent of AI.

Next: More on why Flow Management is necessary for ITIL success.

(lesson 2 in the SOFF Foundation course)

* Source: HappySignals Global IT Experience Benchmark Report.

Why not subscribe to the Service System blog written for HDI SupportWorld, to receive a key insight about IT support's struggles weekly...