Management by exception is a way of spending a manager's attention. Standards define what normal looks like. Work that meets them runs without review. Only the cases that fall outside, the especially good and the especially bad, get escalated. The idea is more than a century old. The cost of finding the exceptions, and of understanding them once found, is what kept it from working at scale.
Where does management by exception come from?
Frederick Winslow Taylor named it in Shop Management, the paper he presented to the American Society of Mechanical Engineers in 1903. He described a manager "fairly swamped at his desk with an ocean of letters and reports" and proposed the reverse: the manager "should receive only condensed, summarized, and invariably comparative reports," with "all of the exceptions to the past averages or to the standards pointed out, both the especially good and especially bad exceptions."
Note the detail that most summaries skip. In Taylor's design an assistant went over the summaries before the manager saw them. Somebody had to read everything so the manager could read less. Lester R. Bittel later gave the idea a book-length treatment in Management by Exception (1964).
How does it work in an operation?
Three parts have to exist before the principle does anything.
- A standard. A tolerance, a service level, a policy limit, a historical average.
- Measurement against it, on every case, not on a sample.
- An escalation route that delivers the exception to someone who can act on it, with enough context to act.
A finance team that pays matched invoices automatically and reviews only those outside price or quantity tolerance is managing by exception. So is a service desk that alerts a supervisor only when a ticket is about to breach its response target.
What does AI change?
Rules-based systems could already measure numbers against thresholds. They could not read. Most operational exceptions arrive as an email, a PDF, a free-text note or a customer's own description of the problem, and deciding whether a case is routine meant a person reading it.
AI takes over the job Taylor gave to the assistant. It reads each case, decides whether it fits the standard, resolves it when it does, and assembles the context when it does not: the account history, the policy that applies, the similar cases and the reason it was held. The manager or specialist receives a short queue of real exceptions, each one ready to decide. That hand-off is what human in the loop design specifies, and it is the core of operational AI.
How is it different from exception management?
The two terms sound alike and mean different things. Management by exception is a principle about where managers look. Exception management is a back-office process, often supported by dedicated software, that catches transactions failing straight-through processing (an unmatched payment, a rejected order, a failed settlement) and works each one to resolution. An exception management process is one place the principle gets applied.
What goes wrong?
Thresholds get set once and never revisited, so either nothing escalates or everything does. When exceptions make up a large share of the volume, the standard is wrong, and the fix is to change the process. Good exceptions get ignored, although Taylor asked for both kinds: an unusually fast team or an unusually clean month holds information too. Managers who see only deviations also lose their feel for normal work, so the best operations still sample routine cases every week. In safety-bound settings such as public transit, the escalation route has to be faster than the risk it reports.
