Mark Boyer
Book to speak
The Service Flow Benchmark

Nobody had ever measured this.

Until this benchmark there was no published figure for how much of IT service demand is failure demand, or how little of the time our work is actually moving. The findings put a number on both. Six questions, ninety seconds, and every answer makes the number less of a guess.

The findings are published. On their own estimates, 400 practitioners put their failure demand at 36% on average, and the work waits nine days in ten. Read the findings, or download the report (PDF, 15 pages, free).

Answer as honestly as you can, in ranges. If you do not know, say so. That is a real answer and one of the more interesting findings: most service organisations cannot tell you these numbers, because nothing they currently measure would reveal them.

Anonymous. No organisation name, no job title, nothing that identifies you or your employer. Results are only ever published in aggregate, and never for a group small enough to guess. Please do not enter anything commercially sensitive.

Question one

Who do you serve?

The commercial relationship changes almost everything about how these numbers behave.

Question two

How big is the organisation you serve?

People supported, not people in the IT team.

Question three

Which sector?

So the benchmark can be cut by industry once there is enough of it.

Question four

How much of your demand exists because something already went wrong?

Failure demand: 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.

Question five

Of the time you hold a piece of work, how much of it is actually being worked on?

Flow efficiency. Take a typical request: minutes of genuine hands-on work, divided by the hours or days between someone raising it and it being done.

Question six

What utilisation do you plan your teams to?

The figure capacity planning assumes, not the one anybody admits to in a bad week.

Answers are stored by Netlify, who host this site. Like any web form, their system also records the submitting IP address and browser. I never look at it, it is never published, and it plays no part in the findings, but I would rather say so than claim an anonymity the technology cannot give. The form asks for nothing that identifies you or your employer unless you choose to add an email address.

Why this is worth ninety seconds

Failure demand was named by John Seddon in the early nineties, and the numbers most often quoted, forty to sixty per cent of demand in conventional service organisations, come from consulting observation rather than published research. Flow efficiency benchmarks have a similar problem: the widely repeated figures trace back to practitioner experience across engagements, not a dataset anyone can inspect.

For IT services specifically, there is nothing at all. No published failure-demand figure for a service desk. No flow-efficiency baseline. The profession has spent thirty years measuring how busy its people are and almost no time measuring how long its work waits.

So this is not a survey about satisfaction or maturity, and it is not sponsored by anybody selling a platform. It is an attempt to establish, for the first time, what these numbers actually look like across the industry. The findings will be published free, with the methodology and its weaknesses stated plainly: it is self-selected, self-reported and unverified, and people scoring their own failure demand almost certainly under-report it, because the number is unflattering.

If you want to work out your own figures properly rather than estimate them, that is what Shift Right does.

Two terms, plainly

What is failure demand? Failure demand is 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. John Seddon named it in the early nineties. It is not the fault itself, it is the contact the fault generated, and in conventional service organisations it is commonly put at forty to sixty per cent of everything coming in. No published figure exists for IT services. Closing that gap is the point of this benchmark.

What is flow efficiency? 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. Utilisation tells you how busy your people are; flow efficiency tells you how long their work waits, and almost nobody measures the second. Practitioner experience puts typical figures in low single digits. For IT services, nobody has published one. Yet.