Failure demand: reduce work created by earlier failures

What should have happened earlier that would have made this contact unnecessary? Use this page to investigate avoidable chasing, corrections and repeat contacts—not to discourage people from asking for help.

John Seddon defines failure demand as “demand caused by a failure to do something or do something right for the customer”. The useful distinction is why the work arose, not whether the person contacting you is difficult.

Not every repeat contact is failure demand

Total calls, tickets or visits mix these types together. Counting activity alone cannot tell you whether needs were met—or why customers returned.

Examples: healthcare and other services

Healthcare: a patient chasing a referral that was agreed but never sent may be experiencing failure demand. Planned monitoring, a new symptom or clinically necessary reassessment is not automatically failure demand. A reattendance alone cannot establish inadequate earlier care.

Other services: an incorrect invoice may generate correction calls. Software contacts may reveal an unclear interface, missing information or a defect. Investigate the cause; do not classify all support as unavoidable or all questions as waste.

These are illustrative examples, not findings about a particular service. Provide necessary help and respond to safety concerns while investigating.

Find and reduce the demand at its source

  1. Listen to actual requests. Record what people say they need, the earlier events and whether the need was resolved. Include relevant channels and different periods; do not rely only on existing ticket labels.
  2. Classify with the people doing the work. Agree examples of value, failure-related and uncertain demand. Review disagreements and missing evidence. A convenient sample may reveal patterns, but does not establish their prevalence across the service.
  3. Trace a recurring pattern. What was promised, missing, unclear or inaccessible? Follow the whole journey, including other teams. Use evidence-led investigation, not a search for someone to blame.
  4. Test a change to the conditions producing it. Examples include reliable handovers, clearer information or fixing a recurring defect. Check whether the change actually meets the customer’s need; documentation or automation alone may not.
  5. Use released capacity deliberately. Agree how it will support customers, reduce waiting or make room to improve. Less avoidable work does not automatically become usable capacity at the right place and time.

Protect focus with clear response arrangements, but do not just shield experts from requests while leaving the failures in place.

Check improvement—not just fewer contacts

Track the relevant contact types, unresolved needs and customer outcomes alongside waiting, workload and access. If reporting a proportion, show the denominator and keep definitions consistent. Check whether contacts moved channel or people gave up trying.

A fall in total contacts does not prove failure demand fell. Demand mix, service access and other changes may explain it. A chart or Bootstrap CUSUM analysis can help identify a performance change, not confirm its cause or permanent elimination. No detected change is not automatically proof of no benefit.

Choose useful measures →
Definition and optional reading

John Seddon and Vanguard, Failure Demand: the original concept, defined in customer terms. Use the definition to investigate your service; do not import another organisation’s reported percentages as your own.

What’s your next useful question?

Which recurring request could we trace back to an unmet need or an earlier failure?

Manage competing commitments with Focus and prioritisation →
Return to Where might the difficulty lie? →