Failure Demand And What Your Support Queue Is Telling You

Service operations are managed almost everywhere as a cost to be minimised. The volume of contacts is treated as a given, an external weather system generated by customers, and the management task is to handle that volume as cheaply as possible. Hence the familiar levers: reduce average handle time, raise first contact resolution, deflect to self-service, offshore, automate, compress.

John Seddon's contribution, developed from Deming and from years inside service organisations, was to challenge the premise rather than the levers. Demand is not weather. A large share of it is manufactured by the organisation itself, and organisations that squeeze the handling of it reliably manufacture more.

The distinction is simple enough to explain in a sentence and takes years to work through fully. Value demand is a customer asking you to do something you exist to do — buy the product, use the service, change their arrangements. Failure demand is demand caused by a failure to do something, or to do something right, for the customer. The customer is contacting you because you did not do what you said, or did it wrongly, or did it in a way they could not understand, or did it so slowly they had to check.

Failure demand is not a customer service problem. It is a signal about the rest of your business, arriving in the one place in the organisation that is structurally least able to act on it.

What the split usually looks like

The proportion of failure demand in a service queue is commonly high — in many service operations, the majority of contacts. It is worth being careful here, because the figure varies enormously by sector and by process maturity, and quoting someone else's number will get you into an argument about comparability rather than about your own system. Measure your own. The number will be higher than your operations leadership expects, and the value of the exercise is the specificity, not the headline.

The classification is less obvious than it sounds, and the boundary cases are where the insight lives.

"Has my order shipped?" is failure demand. The customer would not ask if they had been told, or if the promise had been reliable enough to trust.

"I do not understand this bill." is failure demand. The bill is your artefact and its comprehensibility is your responsibility.

"I am calling to chase the thing I called about last week." is failure demand twice over — a failure to resolve, plus a failure to keep the customer informed while not resolving.

"I would like to add a service." is value demand.

"Your website would not let me complete this, so I am calling." is failure demand generated by a channel strategy, which is a particularly awkward category because it is frequently created by the very deflection programme intended to reduce cost.

Where reasonable people disagree, the test that resolves most cases is a counterfactual: if everything upstream had worked as intended and been communicated clearly, would this contact exist? If not, it is failure demand, regardless of how polite the customer was or how routine the handling.

Why efficiency drives increase total demand

This is the counter-intuitive result, and it is the reason the failure demand framing matters rather than being a rhetorical relabelling.

Consider the standard efficiency intervention: reduce average handle time. The mechanism is pressure — targets, monitoring, scripts, wrap-up limits. The intended effect is more contacts handled per hour with the same staff. The observed effect in many operations is a rise in total contact volume, and the causal chain is not mysterious.

Truncated contacts do not resolve. An adviser under time pressure closes the contact at the point where the immediate question has been answered rather than where the customer's problem has been solved. The unsolved part returns as a second contact, often to a different adviser with no context.

Scripts prevent the adviser doing the one thing that would end it. Handling designed for speed and consistency removes the adviser's latitude to deal with the whole of a messy case. The residue comes back.

Specialisation adds handoffs. Splitting work into narrow queues raises measured efficiency per queue and increases transfers, and each transfer is a fresh queue plus an opportunity for the customer to give up and start again.

Deflection without a resolution path relocates demand. Pushing customers to self-service that cannot handle their case does not remove the contact; it delays it, and the customer arrives later, more annoyed, having already spent effort, requiring longer handling.

Chasing is created by delay. Every promise not kept generates progress-chasing contacts. Chasing volume is almost purely a function of how long things take and how well you communicate while they take it, and it is one of the largest and most reducible categories in most queues.

The pattern generalises beyond service operations. Local optimisation of a step, measured locally, frequently degrades the end-to-end system. It is the same error as improving a non-constraint step in a value stream and finding that nothing gets faster — the argument set out in why busy teams are slow teams — expressed in the language of demand rather than flow.

The support queue as an instrument

Once you classify demand by its originating cause rather than by its handling category, the service queue becomes the best-instrumented defect detector in the organisation. It receives, continuously and at volume, direct evidence about every customer-facing process the business runs.

Almost no organisation uses it this way, for a structural reason: the function that holds the information is not the function that owns the cause, and there is usually no route between them other than escalation.

Build the route deliberately. For each category of failure demand, identify the originating function and the specific upstream decision that produced it.

What the customer says	Failure demand cause	Who actually owns the fix
Where is my order	Unreliable promise, or no proactive update	Fulfilment and operations
I do not understand this charge	Billing design and communication	Finance and product
It did not work as advertised	Expectation set by marketing, or product defect	Marketing and product
I have been passed around	Process design across team boundaries	Operating model owner
I am chasing last week's request	Cycle time in a back office queue	That back office function
Your form would not accept this	Channel or system design	Digital and product

The reporting that follows should be a standing item, aimed outward. Not a service performance report, but a demand report: this is what our customers contacted us about, this is what caused it, this is what it cost, this is which function can remove it. Volumes and costs attached to named functions change conversations that qualitative feedback never does.

Who should own the fix

The most important structural point in this article: the service function cannot fix failure demand, and holding it accountable for reducing contact volume guarantees the wrong behaviour.

If the service operation is targeted on reducing contacts while owning none of the causes, the only available levers are making contact harder — hiding phone numbers, lengthening self-service paths, adding friction before a human. Contact volume falls. Customer dissatisfaction rises, complaints move to channels you do not count, and the underlying defect continues untouched while the measure improves. This is Goodhart's Law operating exactly as specified.

Three ownership rules keep the system honest.

Failure demand belongs to the function that caused it. The category, the volume, the cost and the remediation plan go to fulfilment, billing, product or marketing as appropriate. Service owns the detection and the analysis, not the remedy.

Someone senior must own the total. Because failure demand crosses functions and most categories sit outside service, reduction requires a sponsor with authority across the value stream. In practice this is a chief operating officer or equivalent. Without that sponsorship the analysis is produced, admired and shelved.

Advisers need latitude and a feedback channel. The people taking contacts know precisely what is broken, usually in more detail than any dashboard captures. Two things make that knowledge usable: the authority to do whatever it takes to resolve a case fully, and a low-friction route for reporting causes that is read by someone who can act. Both are cheap. Both are unusual.

The measurement trap

Average handle time is the most entrenched measure in service operations and one of the most damaging, for a reason worth stating precisely: it measures the cost of one contact while ignoring the number of contacts. Reducing it while increasing total volume raises total cost and worsens the customer's experience, and the reporting will show an improvement throughout.

First contact resolution is better but corrupts easily, because in most systems it is self-reported by the person whose number it is. What it actually needs to measure is whether the customer came back, which requires customer-level rather than contact-level data and is therefore often unavailable in exactly the systems that report it most confidently.

Four measures serve better, and they work together.

Demand volume split by value and failure. Tracked over time, by category. This is the headline and should be reported to the executive rather than kept inside operations.

Total contacts per customer journey. Not per contact — per customer, per end-to-end thing they were trying to achieve. This is the number that falls when the system genuinely improves and that cannot be improved by handling contacts faster.

End-to-end resolution time as a distribution. From the customer's first contact to their problem actually being resolved, including every internal queue and transfer, reported as median and eighty-fifth percentile. Averages hide the long tail, and the long tail is what generates chasing.

Failure demand cost attributed to originating function. Volume multiplied by fully loaded handling cost, plus the downstream cost of the failure itself where you can estimate it honestly. This converts a service statistic into a business case owned by someone who can act.

Notice what is absent: any measure of adviser activity. Adviser productivity measures are precisely the instruments that generate the truncation, scripting and transfer behaviours that create failure demand in the first place. The most reliable way to reduce the cost of your service operation is to give the people in it the time and authority to end a customer's problem completely, and then to remove the causes they identify.

What to do on Monday

Put three experienced advisers and one manager in a room with live contacts for two days. Tally every contact as value or failure demand, in the customer's own words, ignoring the existing disposition codes entirely. Two days is enough to change the conversation.

Sort the failure demand into causes, and sort the causes by originating function. Take the top three to the executive team with volumes and an honest cost estimate attached.

Pick the single largest category — it is very often chasing, generated by an internal queue somewhere else — and trace it to the upstream process that produces it. Measure that process end to end as a value stream and you will usually find the same low flow efficiency that appears everywhere else.

Suspend one adviser productivity target for one team for a month. Replace it with a single instruction: resolve the customer's problem completely, whatever that takes. Measure contacts per customer journey and end-to-end resolution time across the period, not handle time.

Then put failure demand volume on the operating review as a standing item, owned by a named executive, reported by cause and by originating function. The measure only does its work when it is read by people who can remove the cause, and the reason it usually is not is that nobody outside the contact centre has ever been shown it.