Want help applying this guide?Ask the DripTell team
Failure demand is customer contact that exists because an earlier part of the service failed. Measure it by reviewing a representative sample of inbound contacts, asking whether each contact would still have been necessary if the service had worked as promised, and then reporting both its share of contacts and its share of handling time.
A second contact is not automatically failure demand. A customer may return with a new question, provide requested evidence, or report a new event. The cause matters more than the count.
The Scottish Government's 2026 definition describes failure demand as avoidable or system-generated need that arises after an earlier intervention was absent, insufficient, or ineffective. In customer service, that includes chasing a promised update, repeating information lost during a handoff, reopening an issue that was closed too early, or asking why an expected action never happened.
| Area | What to verify |
|---|---|
| Start with the contact that should not exist | Use one counterfactual question throughout the review. |
| Classify the cause as well as the contact | A single failure demand tag tells you how much work exists, but not what to fix. Give every classified contact an originating cause. Keep the list short enough that reviewers can apply it consistently. |
| Build a review sample you can defend | Start with a time-bound sample from every meaningful inbound channel. Include different days, hours, languages, teams, and common reasons. Enlarge it for high-volume or high-risk areas. |
| Measure contact share and work share | Report at least two numbers. |
Start with the contact that should not exist
Use one counterfactual question throughout the review.
Would this contact still be necessary if the business had done the earlier work correctly and kept the customer properly informed?
If the honest answer is no, the contact is likely failure demand. If the customer is making a new request or completing an agreed next step, it is probably value demand, meaning contact the service exists to handle.
Imagine a customer asks when an order will arrive. The first enquiry may be normal value demand. Support promises an update by Tuesday. On Thursday the customer messages again because nothing arrived. That second message is failure demand caused by a missed promise. If the customer returns after delivery to ask for a VAT invoice, that is a different need, not another failure.
Classify the cause as well as the contact
A single failure demand tag tells you how much work exists, but not what to fix. Give every classified contact an originating cause. Keep the list short enough that reviewers can apply it consistently.
- Missing or late action
- Missing, late, or unclear update
- Wrong or incomplete answer
- Lost context or repeated information
- Premature closure
- Broken self service or automation
- Policy or authority gap
- Unknown after review
Record the customer need separately from the cause. A delivery question is the need. A missed dispatch update is the cause.
Do not assign the cause to the agent who received the later message by default. The failure may sit in fulfillment, billing, product design, a supplier, an automation rule, or an earlier support decision. The receiving agent is often the person revealing the failure, not creating it.
Build a review sample you can defend
Start with a time-bound sample from every meaningful inbound channel. Include different days, hours, languages, teams, and common reasons. Enlarge it for high-volume or high-risk areas.
For each contact, preserve six facts.
- The customer and underlying need
- The earlier promise, action, or expected service event
- What actually happened
- Why the customer contacted the business now
- The failure-demand decision and confidence
- The originating cause and owner of the corrective action
Have two reviewers classify an initial slice. Discuss disagreements and refine the rules before measuring the whole period. Keep an uncertain category instead of forcing weak evidence into success or failure.
Reopened cases, repeat messages, channel switching, and phrases such as “any update” are useful discovery signals. They are not proof by themselves. Zendesk's current support reporting guidance recommends examining reopens, multiple requests from the same customer, ticket age, priority, and category. A defensible failure-demand review connects those signals to the same customer need and the earlier service event.
Measure contact share and work share
Report at least two numbers.
Failure demand contact share equals classified failure-demand contacts divided by all eligible inbound contacts.
Failure demand work share equals handling time spent on classified failure demand divided by handling time for all eligible inbound contacts.
The National Audit Office review of DWP customer service is a useful real example because it separated avoidable, potentially avoidable, and unavoidable call time. It also identified progress chasing as a major source of avoidable contact. The important lesson is the method, not a benchmark borrowed from a different service.
Break both measures down by need, cause, channel, language, product area, and originating team.
Connect the journey before automating the tag
Failure demand is easy to miss when the first WhatsApp conversation, later Instagram message, and reopened case look unrelated. Link contacts by customer and need where consent and policy allow. Preserve promised dates, ownership, status changes, automation versions, handoff reasons, and completion evidence.
A DripTell shared inbox can keep supported-channel history, ownership, notes, status, and next actions together so a reviewer can see the sequence.
Automate candidate signals only after people can classify them reliably. Let rules surface cases for review, not declare every repeat contact a failure.
Use the measure to remove a cause
Choose the largest preventable cause that a named team can change. Write a specific intervention, such as sending a truthful dispatch update before the promised time, retaining handoff context, or preventing closure until a downstream action is confirmed.
Run the same classification after the change. Check that failure-demand contact share and work share fell for the targeted cause without increasing abandonment, complaints, or blocked access to help. If the tag count falls only because customers cannot reach you, the service did not improve.
The goal is not a perfect dashboard. It is fewer customers having to ask the business to finish work it already promised to do.
To map the evidence across your own service journey, contact DripTell.
Frequently Asked Questions
What is the difference between failure demand and repeat contact
Repeat contact is an observable event. Failure demand is a judgment about why the contact exists. A repeat may concern a new need, while a first contact can be failure demand if an earlier non-support process failed.
Should all progress chasing count as failure demand
No. It counts when the business missed a promised update or left expectations unclear. A customer asking within an agreed waiting period may be seeking reassurance, so review the promise and context.
How large should the review sample be
Use a sample that covers each important channel, reason, language, and operating period. Expand it until classification is stable for high-volume causes, and report the sample size and uncertainty rather than claiming false precision.
Should failure demand be an agent performance metric
Usually not. The cause often sits outside the receiving agent's control. Use the measure to find failed processes and assign corrective action to the team that owns the originating control.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy