IT services run on 36% failure demand.

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 time you hold a piece of work in which it is actually being worked on: minutes of genuine effort divided by the days between raised and done. 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 full working week and touched for about 24 minutes 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 adds 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. Organisations 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 the time work spends waiting rises sharply, not steadily, as utilisation approaches 100 per cent. The last few points of utilisation cost more waiting than all the rest put together. It is sixty-five years old and it is still not on the capacity planning slide.

The benchmark reproduces it in self-reported data. The share reporting flow efficiency under 5 per cent roughly triples from the coolest band to the hottest, and the estimate falls from 14 to 6 per cent along the way. Utilisation is the number capacity planning is proudest of. It is also the one that makes the queue.

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

Providers are more than twice as likely as internal teams to know their failure demand. It is not that they have less of it: the provider estimate is 37 per cent against 34 for internal teams, and 42 per cent of providers put it at 40 per cent or higher. They have roughly the same amount. They categorise it.

The commercial reading is the uncomfortable one. If your model bills per ticket, failure demand is revenue, and nobody leaves revenue uncounted. For an internal team it is pure cost with nothing on the other side, and nobody counts a cost that never appears as a line. The incentive to measure runs exactly opposite to the incentive to eliminate.

The gap closes on flow efficiency, where 34 to 43 per cent of every group cannot answer. Nobody invoices for waiting, so nobody measures it. The 51 who serve both customers and colleagues know least of all. Two masters, measured for neither.

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 data they do not. Organisations 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: how many hands, how many handoffs, how hot we run. Programmes routinely attack one and report success on the other: the desk halves its repeat contacts and every remaining request waits exactly as long as before.

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. Manufacturing (6 per cent) and public sector (7) report the longest waits; financial services, professional services and technology sit at 11 to 12. Retail and hospitality reports the lowest failure demand (30 per cent) and 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: organisations 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 smallest sector cell is 23 responses and the largest 77. Every cell clears the publishing floor. None is large enough to settle an argument, and a difference of a point or two between two 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 cut with fewer than 20 responses is published, anywhere. Where a cell falls below it the table says so rather than showing a number.

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, then divide by the hours between it being raised and being closed. 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.