Failure Demand

Not all demand is equal. John Seddon’s distinction between value demand and failure demand is one of the most practically important ideas in systems thinking for service organisations. Failure demand is demand caused by a failure to do something, or to do something right, for the customer. It is waste masquerading as work — and it is invisible in most management information systems.

The definition

John Seddon, a British management thinker and critic of command-and-control management, introduced the concept of failure demand in his work on systems thinking in service organisations, most fully developed in Freedom from Command and Control (2003) and Systems Thinking in the Public Sector (2008).

Seddon’s central observation is simple: in any service organisation, a significant proportion of inbound contacts are not customers asking for something new — they are customers returning because something was not done, or not done correctly, the first time. This demand is created entirely by the organisation’s own failure. It consumes capacity, but it creates no value.

Value demand vs failure demand

The critical point is that failure demand and value demand look identical in most management information systems. Both generate a contact, a ticket, a call, a visit. Both consume staff time. Both appear in workload statistics. The organisation cannot manage what it cannot distinguish — and most organisations do not distinguish them.

Why failure demand is invisible

Failure demand is systematically invisible for three structural reasons.

Volume metrics hide the distinction. A call centre that receives 1,000 calls per day records 1,000 calls. Whether 400 of them are customers chasing incomplete work from last week is not visible in the volume figure. Management sees high demand and responds by adding capacity — which handles more failure demand, which obscures the underlying failure, which generates more failure demand. The organisation becomes permanently busy handling the consequences of its own failures.

Target-setting amplifies it. In the NHS and many public services, performance targets measure response time — how quickly a contact is handled — rather than whether the underlying need was met. A GP practice that answers calls quickly but fails to resolve the patient’s problem will generate multiple callbacks. Each callback is counted as good performance (answered quickly) while representing a failure (problem not resolved). Seddon called this “sub-optimisation” — the organisation meets the target while missing the point.

It is attributed to customers rather than systems. The natural management response to high inbound volume is to ask why customers are contacting so frequently — implying the problem lies with customer behaviour rather than service design. Seddon’s insight is that the question should be directed at the system, not the customer: what did we fail to do, or fail to do correctly, that caused this contact?

Failure demand in the NHS

The NHS is one of the most extensively documented settings for failure demand. Seddon’s work in NHS primary care, urgent care, and housing benefit found failure demand accounting for anywhere from 40% to 80% of total contact volume in some services.

In NHS A&E, a significant proportion of attendances are patients who could not access a timely GP appointment. The A&E attendance is failure demand created by primary care capacity constraints. Managing A&E capacity without addressing GP access addresses the symptom rather than the cause. Bootstrap CUSUM on A&E attendance finds no structural improvement across 15 years — the failure demand from primary care has been consistent throughout.

In GP appointments: a patient books an appointment because their medication review was overdue (value demand). A second appointment is booked because the prescription was issued incorrectly (failure demand). A third is booked because the referral letter was never sent (failure demand). The practice records three appointments. Two of them were created by its own failures. The GP appointments analysis on this site finds that doctor contact rates have not changed since 2018 despite appointment volumes rising — consistent with increasing failure demand absorbing the additional capacity.

Failure demand in service organisations

The pattern is identical in commercial service organisations. A specialist B2B software company with a large installed base receives support contacts that fall into three categories:

• Value demand — legitimate support: the customer has encountered a genuine edge case, a new use case, or a software defect. This is unavoidable and represents the real support workload.
• Failure demand — usability failures: the customer cannot complete a task because the interface is unclear, the documentation is absent, or the error message is unintelligible. This demand disappears when the UX is fixed or the help article is written. The work to handle these contacts is real. The need for it is not.
• Failure demand — process failures: the customer contacts support because a promised action was not completed — a configuration change was not applied, a scheduled task did not run, an upgrade was not communicated. Each of these contacts is created by the organisation’s own process failure.

How to reduce failure demand

Reducing failure demand requires identifying it first — which means classifying inbound contacts by type rather than simply counting them. A practical method:

1. Classify a sample of contacts as value demand or failure demand. This requires reading or listening to the actual contact, not just reading the ticket category. A one-week sample of 50–100 contacts is usually sufficient to identify the major failure demand patterns.
2. Find the upstream failure for each failure demand category. What should have happened that did not? What was unclear, broken, or absent? Apply the 5 Whys to each failure demand category to find the root cause.
3. Fix the upstream failure at the system level. Write the help article. Fix the UX. Automate the restart. Set expectations before the customer needs to chase. The fix eliminates the failure demand permanently — it does not just handle it more efficiently.
4. Measure the reduction using Bootstrap CUSUM on the total contact volume. A structural downward change point confirms that the fix eliminated a class of failure demand rather than just handling it faster.

Bootstrap CUSUM and failure demand

Bootstrap CUSUM on total contact volume distinguishes three situations that look identical in a simple monthly count:

• Stable failure demand: A flat Bootstrap CUSUM line on contact volume means the failure demand is consistent — the same classes of failure are generating the same volume every period. The organisation is handling it efficiently but not eliminating it.
• Increasing failure demand: An upward Bootstrap CUSUM change point on contact volume, occurring when no new customers or new products were added, indicates growing failure demand — either a new failure was introduced, or an existing failure worsened.
• Failure demand eliminated: A downward Bootstrap CUSUM change point after a specific fix confirms that the fix eliminated a class of failure demand. The change point date should coincide with the fix. This is the Study step of the PDSA cycle: the pre-specified Bootstrap CUSUM prediction was a downward change point in contact volume within Z periods of implementing the restart script or help library.

Related concepts