IT service teams put their own failure demand at 36%.

Failure demand was named by John Seddon in the early nineties: demand that exists only because something already went wrong. Chasing an update. Reporting the same fault twice. Asking for something that should never have needed asking. Not the fault itself, the contact it generated.

The figure everyone quotes for it, forty to sixty per cent of demand in conventional service organisations, comes from consulting observation rather than published research. It has been doing service management duty ever since, and nobody has checked whether it transfers. The claim that up to eighty per cent of demand on public services is failure demand has the same problem, and it is a claim about a different population anyway. One policing study, in Gloucestershire, put it at thirty-two per cent. At least that one has a dataset.

Flow efficiency has a similar biography. The measure comes out of lean: the share of the time you hold a piece of work in which it is actually being worked on. The figures most often repeated for it, low single digits, trace back to practitioner experience across engagements rather than anything anyone can inspect.

For IT services there was nothing at all. No published failure demand figure for a service desk. No flow efficiency baseline for service management. The profession has spent three decades measuring how busy its people are and almost no time measuring how long its work waits. This is the first attempt to put a number on both. A flawed number, for the reasons above. Also, for now, the only one.

Of those who know, 67 per cent put failure demand at a quarter or more of everything coming in. 39 per cent put it at 40 per cent or higher, which is where the consulting folklore starts. 10 per cent say it is under 10 per cent. Either they are very good, or they have not looked.

Read it as a floor. The people answering were scoring their own operation, and it is not a number anybody wants to be high. Read it as a range too: the honest statement is that the typical IT service organisation sits somewhere in the 25 to 40% band, with a long tail above it.

At 36 per cent, roughly one contact in three exists to chase, repeat or correct an earlier one. If your model bills per ticket, that is revenue. If it does not, it is pure cost with nothing on the other side. Finding 5 is about which of those you are.

Flow efficiency is the share of the elapsed time between a piece of work being raised and being done in which it is actually being worked on: working time divided by elapsed time. Nobody plans to it, and it shows. Of the 251 who could answer, 43 per cent put it under 5 per cent and 68 per cent under 10. 15 per cent put it under 1 per cent, which is a request open for a week, nights and weekends included, and touched for under two hours of it.

10 per cent report over 25 per cent. There is no way of knowing from this data whether they measured it or are optimists, and the two are not mutually exclusive.

The don't-know rate is highest here: 37 per cent, against 22 per cent for failure demand. The SLA clock measures elapsed time. Timesheets, where they exist, measure effort. Nobody divides one by the other.

Not knowing is not incompetence. Nothing on a standard dashboard would reveal either number. A ticket count does not separate the demand you exist to handle from the demand you created earlier. An SLA clock measures elapsed time, not touch time. The dashboard says the desk is busy. It does not say why, and it does not say how long anything waited.

What the data suggests is that measurement is a habit rather than a metric. If you cannot state your failure demand, there is a 93 per cent chance you cannot state your flow efficiency either. If you can, that falls to 21 per cent. Respondents either look at the work or they do not, and the ones that do not tend not to plan to a utilisation figure either: 60 respondents, 15 per cent, had none of the three numbers.

Which makes the don't-know rate the most reliable finding in this report. It is the one answer nobody had to estimate.

Kingman's formula says waiting time rises sharply, not steadily, as utilisation approaches 100 per cent: the last few points cost more waiting than all the rest put together. It is sixty-five years old and still not on the capacity planning slide.

The survey runs the same way. The share reporting flow under 5 per cent roughly triples from the coolest band to the hottest, and the average estimate falls from 14 to 6 per cent. What it cannot say is what would happen to any one team if it changed its target: this is an association between two self-reported numbers, not an experiment. Utilisation is the number capacity planning is proudest of. In this sample it is also the one that travels most closely with the queue.

One group is missing from the chart: the 90 who do not plan to a figure at all, of whom only 12 could state a flow efficiency, below the publishing floor. Not planning to a number and not measuring the flow travel together.

Internal teams are 2.4 times as likely as providers to answer "we do not know": 27 per cent against 12. Put the other way, 88 per cent of providers could give a figure against 73 per cent of internal teams, 1.2 times as many. Providers do not estimate less of it: their average is 37 per cent against 34, and 42 per cent of them put it at 40 or higher.

The survey asked for an estimate, not a measurement, so it cannot say whether anybody counts anything. One reading fits, and it is the uncomfortable one: if your model bills per ticket, failure demand is revenue, and revenue tends to get a number. For an internal team it is pure cost with nothing on the other side. A hypothesis the data is consistent with, not a finding it establishes.

The gap closes on flow efficiency, where 34 to 43 per cent of every group cannot answer. Nobody invoices for waiting. The 51 who serve both could answer least often of all.

The intuition is that they travel together: an organisation drowning in failure demand should wait longer, because the repeat contacts clog the queue. In this sample they do not. Respondents reporting under 10 per cent failure demand wait about as long as those reporting over 60. A flat line is the least exciting chart in the report and possibly the most useful.

Failure demand is about what comes in. Flow efficiency is about what happens to it once it is in. One is a design problem: are we causing our own demand? The other is a queue problem: hands, handoffs, how hot we run. If they are as loosely coupled as this sample suggests, a programme that attacks one has no reason to expect movement in the other, and should measure both.

If you can only measure one, measure the one you are worse at. You will need both to find out which that is.

The sectors sit within 8 points of each other on failure demand, which is either a real regularity or the limit of what self-report can resolve. Flow is where they separate, among the 6 sectors with at least 20 answers: manufacturing (6 per cent) and public sector (7) report the longest waits; financial services, professional services and technology sit at 11 to 12. Something else, retail and hospitality and education had too few answers on flow to publish. Retail and hospitality gives the lowest failure demand estimate (30 per cent) on exactly 20 answers, alongside one of the highest don't-know rates (36 per cent), which is one way of getting a low number.

Failure demand is flat across size. Flow efficiency is worst in the middle: respondents serving 1,000 to 20,000 people report about 8 per cent, against about 12 at either end. Enough process to wait, not enough scale to fix it.

Read these as indicative. The most answers behind any sector figure is 64; several rest on 20 to 25. None settles an argument, and a point or two between rows is noise.

The sample. 400 responses through markboyer.co.uk/benchmark, 1 to 29 August 2026, collected with a plain web form and stored by the site's host. An email address was optional, was left blank by most people, and played no part in any analysis. Nothing that identifies a respondent or an employer was asked for, and nothing of the kind is held in the published data.

The estimates. Answers are bands, so every single figure is the mean of band midpoints among respondents who could answer. "We do not know" is reported as its own category and is never imputed.

The open top bands are the judgement calls. Putting "over 60%" at 65 or 75 instead of 70 moves the failure demand estimate to 35.2 or 36.6. Putting "over 25%" at 35 moves flow efficiency to 10.2.

The floor. No figure rests on fewer than 20 people who could answer, anywhere. The floor applies to the answers behind each estimate, not the size of the group, so a sector can carry a failure demand figure and no flow figure; the table says so rather than showing a number.

Elapsed time. The flow question did not say whether elapsed time includes nights and weekends. Respondents will have differed, which is one more reason to read the flow figure as a range.

Licence. Published free under CC BY 4.0. Cite it, quote it, reuse the charts; the only condition is attribution and a link to this page.

Failure demand. Take one week of contacts. All of them. For each one ask a single question: would this contact exist if we had done the earlier thing right? Chasing an update is a yes. A second report of the same fault is a yes. A password reset is a real request, badly designed, and you can argue about it later. Count the yeses and divide by the total. It will be higher than the number you would have guessed, which is the point of not guessing.

Flow efficiency. Take twenty recently completed requests, picked at random rather than the ones you are proud of. For each, add up the minutes anyone actually spent working on it, divide by the minutes between it being raised and being closed, and multiply by 100. Count elapsed time on the clock, nights and weekends included; if you leave them out, say so next to the number, because the two versions are not comparable. Average the twenty. If the answer is above 10 per cent, check the arithmetic. If it is above 25, check who chose the twenty.

Then what. Failure demand is a design problem: go to the earliest point in the journey that generated the contact and fix that, not the contact. Flow efficiency is a queue problem: fewer handoffs, smaller batches, and a utilisation target the queue can survive. Neither shows up on a dashboard built to count tickets, which is why neither was ever on one. If you would rather work them out properly than estimate them, that is what Shift Right is for.

Every response makes the number less of a guess. Six questions, ninety seconds, anonymous, and published only in aggregate.