Backlog - Unavoidable? Manageable?

Backlog is a key operational element of any technical support function that services enterprise application customers. Short of instantaneously resolving/answering every issue/question that comes in, you will always have a number of cases or tickets in the process of being resolved. Simply put, all support teams deal with backlog; keep the queue size in check and all is well, but allow it to grow beyond a critical threshold and support agents will struggle to maintain acceptable service levels.

Ticket backlog usually fluctuates over time. This is especially true in the cloud enterprise application space, where online services evolve per a regular cadence (e.g. x2 major releases per year) and customers continuously advance their operations at a blistering pace.

Backlog Boiled Down

While the above image is a gross simplification of how the change rate of backlog can be calculated, it is a useful way to understand the forces that impact a tech support team’s workload. Put simply: 

• Backlog change (b) is a product of incoming workload divided by a team’s ability to process said workload (i.e. the team’s throughput);
• Incoming workload is rarely constant, as the number of active customers (v) changes over time — hopefully increasing through sales growth (!) — and their ongoing activities vary, in terms of number and size of events like adding new functional modules (e);
• How fast a support function can process incoming tickets is determined by its capacity, or a combination of AI bot ‘power’ (ai) and how many active agents are available (æ); agents’ productivity comes from skills, knowledge, processes & standard operating procedures (SOPs), tooling, and more (o).

Demand Management, Monitoring & Event Management, and other ITIL practices factor for dealing with the workload part of the above equation; i.e. the top half of the equation. Many other ITIL practices, including Incident Management, Workforce & Talent Management, and Infrastructure & Platform Management, help account for throughput; i.e. the bottom half of the equation. These are aspects to be considered in other posts.

The ‘Long Tail’ of Backlog

It is important to baseline what your sustainable backlog is, to know what the threshold is for maintaining your SLAs and CSAT targets. (see Marci Reynolds)

Most enterprise applications service delivery organisations target >30 day tickets or cases when tracking and tackling their operational health. This is because a high number of >30 day tickets is “an indication that discipline and accountability have broken down when it comes to ticket management.” (see Jeff Rumburg). While some argue that any >30 day case load is intolerable, I have found that some support organisations accept a percentage of such aged backlog; for example, when allowing for problem-linked cases or where the complexity of used solutions is high while business criticality is low.

But Beware!

As the saying goes, “targets drive behaviours” and overly aggressive targeting of, say, >30 day cases may cause unwanted behaviours and residual damage as teams and/or individuals struggle to avoid the ‘naughty seat’ at *all* costs.  

Far better is to analyse and understand why your backlog is ageing, and carefully adopt *sustainable* continual improvement (CI) changes. To this end, backlog blitzes are best avoided if at all possible: they tend to drive unsustainable burn rates and with the root cause(s) left unaddressed, backlog typically rebounds quickly — “what does up must come down”.