When Commonwealth Bank of Australia announced in July 2025 that it would cut forty-five call-center jobs after introducing an AI voice system, the stated logic was the familiar one: automation takes the simple inquiries, employees concentrate on the complex cases. Within a month the bank reversed the decision. Call volumes had risen. Overtime was being offered. Team leaders were being pulled onto calls.
The staffing reduction had been modeled against expected routine volume. What had not been modeled, apparently, was everything the automated system wouldn't resolve: how many of those calls there would be, how long each would take, what kind of person would need to take it. Reversing inside a month is unusually fast. The miscalculation that made the reversal necessary is not unusual at all.
Automated throughput produces numbers that report easily. Transactions processed, minutes saved, cost per interaction. Exception handling produces value that resists attribution: a fraud pattern caught before it scaled, a regulatory ambiguity surfaced before it turned into a finding, a customer problem resolved in a way that kept a relationship worth many times the cost of the call. The first kind of value shows up on dashboards. The second shows up, if at all, as cost.
The evidence on how organizations actually account for exception work is thin, but what exists points in a consistent direction. Researchers who studied a Portuguese bank's automation program found exception volume tracked as an operational metric, sitting alongside processing time and robot occupancy, while financial returns and headcount reductions lived in a separate category of management metrics. The exceptions were visible as workload and invisible as value. A manufacturing quality study found something more elementary: the accounting system had no place to record quality costs at all, and researchers had to reclassify six months of "normal operating costs" before failure costs became visible. A survey of 479 executives in 35 countries found that more than half had never calculated total cost reduction from automation, which makes exception-specific accounting an unlikely thing to expect.
No standard treatment emerges from any of this. A tendency does. Exception work gets folded into whatever budget line sits closest, and the people clearing the queue rarely get credit when their cases are the reason the automated process gets changed.
The phrase "edge case" helps that tendency along. Calling something an edge case frames it as a boundary condition of the design, a technical problem awaiting an engineering fix. Sometimes that is accurate. But when the cases involve regulatory judgment, disputed charges, or an automated decision that was consequential and wrong, what is being described is a question about governance and risk tolerance wearing a technical label. Klarna's experience is instructive here: after automating 69% of customer-service chats, the company still needed higher-skilled human handling for difficult identity-theft cases and hired freelancers to do it.
As I've argued before, evidence production and accountability are cost-allocation problems. Exception handling belongs to the same family. The work is real, somebody has to do it, and the only open question is whether it gets resourced as a function that matters, staffed with experienced people and positioned where its findings can reach product and policy decisions, or treated as residual cost, pushed toward the cheapest available labor and disconnected from the decisions that generated the exceptions in the first place.
The cases that remain for human handling are, by definition, the ones the system couldn't resolve — likely more complex, more consequential, and more dependent on judgment than the cases the system absorbed. Resourcing that work as though it were the least important part of the operation is a choice about risk tolerance.
The volume of automated decisions keeps growing, and the absolute number of cases falling out of the middle grows with it. Those cases are selected for difficulty. Deciding to staff them thinly is a decision about how much risk an organization is prepared to carry, and it is usually made by people who do not experience themselves as making it. Naming it that way in the budget would be a start.