Intervention Rate

Intervention rate is the share of automated runs in which a person had to step in — to approve something, correct it, finish it, or clean up after it. It is the honest counterpart to any automation percentage, because it measures the work that did not disappear rather than the work that was nominally taken over. It earns its place by being hard to game. A system can report that it handled most of its cases while quietly generating a stream of corrections behind it, and every one of those corrections is a person's time that the business case assumed it would save. Intervention rate is also the number that tells you whether autonomy can safely increase: it falling steadily is the evidence for widening the scope, and it holding flat while volume grows is the evidence against. Defining it requires deciding what counts as an intervention, and the definition should be generous rather than flattering. An explicit escalation counts. So does a silent correction made afterwards by whoever received the output, a case reopened by the customer, a run abandoned and redone by hand, and an approval that was genuinely read rather than waved through. Counting only the escalations the system itself raised measures the system's self-awareness, not its performance. The rate is most useful segmented, because the average hides the shape. Interventions concentrate — in one request type, one customer segment, one integration that returns awkward data, one time of day when the upstream system is slow. A high overall rate driven by a narrow band is a fixable engineering problem; the same rate spread evenly is a scope problem, and the answer is to narrow what the automation attempts rather than to keep tuning it. Read alongside cost, it also settles arguments. Intervention is where the labour savings actually go, so an automation with an unremarkable rate but expensive interventions — senior people, slow context-rebuilding, unhappy customers — can be worse value than one that intervenes more often but cheaply.