The request on my desk was for two more people. Our internal service desk at a large telecom had watched its ticket volume climb for three straight quarters, the queue was aging, and the team lead had done everything right: trend charts, handle times, a clean business case. I was ready to sign it. Before I did, I asked for one thing I had never asked for before. I wanted to know how many of those tickets should never have existed.
Nobody knew. That gap turned out to be the most useful thing I learned about operations that year.
The question I should have asked years earlier
The idea I had stumbled into already had a name. The British occupational psychologist John Seddon calls it failure demand: demand caused by a failure to do something, or to do something right, for the customer. Its opposite is value demand, the work your team exists to do in the first place. Someone asking for a new laptop is value demand. The same person calling back three days later to ask where the laptop is, that’s failure demand. So is the call after the laptop arrives without the software they asked for.
Seddon’s firm, Vanguard, says on its own explainer of the concept that failure demand routinely runs at 40 to 60% of total customer demand in conventional organizations, and as high as 80% or more in health and social care and in utilities. Those are a consultant’s numbers, so hold them loosely. But independent work points the same direction. An April 2026 report from the NHS Strategy Unit, prepared for The Health Foundation, cites a GP-led analysis of 599 consultations in a large practice that found 19% arose from system failures rather than new clinical need. Even at the low end, that’s roughly one appointment in five created by the system itself.
The trap is that failure demand looks exactly like growth on a volume chart. Every chase call is a ticket. Every reopened case is a ticket. Your dashboard counts them all the same, so a team that’s getting worse at the work looks like a team that’s getting busier, and busier earns headcount.
Two weeks with a tally sheet
We did not buy software for this, and I’d tell you not to either. I asked the team lead to have every analyst add one field to each ticket they handled for two weeks: was this the first time we were hearing about this need, or was the person contacting us because something we did earlier hadn’t worked?
Three rules made the sample honest:
- The person handling the ticket made the call, in the moment. Not a reviewer a week later reading the notes. The analyst on the phone knows when someone is chasing.
- “Unsure” was a valid answer. We wanted signal, not false precision, and forcing a binary would have pushed the ambiguous ones into whichever bucket felt safer.
- No names on the summary. This was about the system, not about who closed which ticket too early. If people had thought it was a performance review, the count would have been fiction by day three.
Two weeks was enough. Patterns in service work repeat fast, and by the second Thursday the categories were obvious.
What the count actually showed
A little over a third of the tickets were failure demand. They clustered into three groups, and none of them were the analysts’ fault.
Chasing. The largest group was people asking for status on something already in the queue. Our ticket system sent an acknowledgment when a request was logged and nothing after that until it was closed. For a request that took five days, that was five days of silence, so people called. Every one of those calls pulled an analyst off real work to look up a ticket and read the status back.
Reopens. Tickets closed on the first fix attempt, before anyone confirmed with the requester, came back. The handle time metric rewarded closing fast, so the team closed fast. I had built that incentive myself, which was not a comfortable thing to realize. I’ve written before about how the number you reward becomes the behavior you get; this was a live example sitting in my own queue.
Policy echo. A security change had shortened the password expiry window months earlier. Nobody connected it to the service desk, but password resets had climbed right alongside it. A decision made in another department was generating work in ours, every day, and nobody had a line on any chart that showed the link.
The contact center research lines up with what this costs beyond hours. SQM Group’s 2021 benchmarking of first call resolution found a 16% drop in customer satisfaction for each additional call a customer needs to get an issue resolved, and that every 1% improvement in first call resolution cuts operating cost by about 1%. Your internal customers are no different. The person chasing their laptop for the third time is not forming a generous opinion of your team.
The fixes were boring, and none of them were people
We addressed each cluster at its source:
- Chasing: we added automatic status updates at two points in the workflow and gave requesters a page to check their own tickets. Chase calls dropped sharply within a month.
- Reopens: we changed the closure rule so a ticket closed only after the requester confirmed the fix or 48 hours passed without a reply. Handle time went up slightly. Total work went down.
- Policy echo: I took the password data to the security team. We didn’t reverse their decision; we added self-service reset, which they were happy to support once they saw the volume.
We did not hire the two people. Within a quarter the queue was younger than it had been in a year, with the same headcount. The business case was correct about the volume. It was wrong about what the volume meant.
None of this required brilliance. It required looking at the work by type instead of by count. That’s the same shift I describe in the posts on chasing problems to their root cause and cutting toil: the fix is almost never at the point where the pain shows up.
Why I never made it a target
The obvious next step would have been to set a goal: get failure demand under 20%. I didn’t, and there’s a public example of why.
In 2008 the UK government adopted avoidable contact, its version of failure demand, as one of 198 national indicators for local councils, known as NI 14. Councils had to sample and report it. Seddon, the person who coined the concept, argued against it: make it a target and organizations will be motivated to under-report it rather than remove it. Vanguard’s own page is blunter: “Setting targets will only lead to cheating.” The NHS Strategy Unit report reaches a similar conclusion, warning that the concept’s fuzzy edges make it a poor fit for hard targets and a much better fit as a lens for improvement.
So we treated the tally as a diagnostic we reran every six months, not a scorecard. The team owned the categories. The moment it became a number someone got judged on, it would have stopped telling us the truth.
Your team probably has this, even if it never answers a phone
Failure demand is easiest to see in a service desk, but it isn’t limited to one. Every team that receives requests receives some that it caused. A finance team answers the same budget question from six managers because the guidance memo was unclear. An engineering team fixes a bug that shipped because acceptance criteria were vague. A project team runs a second kickoff because the first one didn’t settle who decides. Some of that overlaps with rework, but failure demand is the wider lens: it includes every message, meeting and request that exists only because something upstream didn’t land.
The test is the same one I asked for: for two weeks, have the people doing the work flag anything that showed up because something earlier didn’t work. Keep it anonymous. Accept “unsure.” Then look for clusters, and fix them where they start. You may find, as I did, that the headcount request on your desk is really a request to stop creating your own work.