What is pump by exception?The mechanics, the ceiling, and the ladder past it.

Pump by exception is an operating model that replaces fixed-route well checks with event-driven visits. SCADA monitors well parameters continuously and raises an exception only when a reading falls outside its normal window, so the field stops driving to wells that are running fine. It is the oilfield’s implementation of management by exception, the older management philosophy that human attention should go only to deviations that matter.

Three layers. Sensing: transducers, flow meters, tank-level sensors, and RTUs stream to a historian at second-to-minute cadence. Rules: configurable thresholds define a normal operating window per parameter, and a breach generates an exception, with compound rules in more capable engines. Delivery: the exception is pushed to the field by mobile app, text, or email, and a lease operator decides whether to drive out and logs the outcome. Every later evolution reuses all three layers rather than replacing them.

Most modern SCADA platforms support exception-based workflows. The requirement is the ability to set configurable alarm thresholds and deliver alerts to mobile devices. If your SCADA can do that, it can run pump by exception, and the layers above it can read from what you already have without a migration.

Reductions vary widely with well density, failure rates, and how carefully alarm thresholds are calibrated, and published deployment summaries differ, so no single number describes detection on its own. What is worth knowing is that the gain erodes over time unless a prioritization layer is added on top, because alarm fatigue puts the wasted trips back. Where the full loop is running, the measured figure at the deployed reference is 35% fewer miles driven for the same coverage, a deployment figure measured across 5,000+ wells at a top 25 private producer rather than a projection.

Pump by exception flags a problem when a sensor threshold is breached. Pump by priority goes further and ranks every flagged issue by its estimated economic impact, so the highest-value work is addressed first rather than every alarm being treated as equal. Detection tells you something happened. A ranked plan tells you what it is worth and who goes first.

It replaces the static threshold with a model of what each well should be doing. Data quality checks validate incoming SCADA readings against expected patterns so sensor drift and communication errors stop generating false exceptions. Anomaly detection learns each well’s operating signature, so deviation is measured against the well rather than against a number somebody set at commissioning, which is what stops threshold drift. Failure-pattern models move some work from reactive to scheduled. Economic scoring then puts a dollar figure on what is left. The point is not the technique, it is that all four fix layers the classical architecture never had.

The market splits into recognizable patterns: dedicated first-generation pump-by-exception platforms with configurable rules engines; mobile-first field capture apps with growing exception capabilities; production accounting suites with exception workflows layered on; equipment-level optimizers for a specific artificial-lift class; and SCADA vendor monitoring stacks with basic alerting in the cloud layer. Each has real strengths and a shared ceiling: they stop at the alarm. The layers that price the alarm, sequence it into a drivable day, and learn from what the crew found sit above all of them and read from whichever one you already run.

Five failure modes repeat. Alarm overload: exception volume scales with well count and rule count while human attention does not. Every exception looks equal: the engine has no concept of working interest, price, or lifting cost. Threshold drift: limits set on a new well go stale as the well declines and nobody is staffed to re-tune thousands of them. No defensible deferral: skipping an item is the right call with no record of why. And the system never learns from what the field found. None of the five is fixed by more SCADA, more rules, or more dashboards. Each is a missing layer, not a missing signal.

A four-rung ladder. Rung 1 rationalizes the queue with per-well bands that follow decline. Rung 2 puts a dollar figure and a confidence band on every row. Rung 3 turns the scored queue into a constraint-sequenced route rather than a list. Rung 4 closes the loop, so outcomes retrain the scoring and the plan re-ranks mid-shift. Each rung pays for itself and no rung’s business case depends on reaching the next one.

No. The moves are additive. The SCADA stays, the historian stays, the alarm discipline stays, and the three layers keep doing their jobs. What changes is what flows through them and how the field consumes it. Teams that present the evolution internally as a rip-and-replace create resistance they did not need to create.

Three rules do most of the work. Set the band per well rather than per fleet, because a limit that is right for a new well is wrong for the same well two years later. Let the band follow the decline forecast, so the definition of normal moves as the well moves and nobody has to re-tune thousands of limits by hand. And require persistence before an item becomes an exception, so a transient that clears on its own never reaches a queue. The fourth rule is the one operators skip: validate the reading first. Calibration drift, stuck values, communication gaps, and physically impossible spikes should be caught and tagged before they are allowed to earn a truck roll.

Regulatory and lease-required visits keep their own cadence and are planned as their own class of work. Exception-driven visits answer the question of where discretionary field attention goes; they do not stand in for a visit a regulator or a lease agreement requires on a fixed interval. In a working deployment both live in one plan: required visits carry their deadline as an absolute constraint, and the value ranking orders everything around them, so a compliance round and a production exception on the same lease are sequenced into the same drive rather than into two trips.

The binding constraint is exception volume and attention, not well count. A queue of 30 to 50 active exceptions per lease operator per shift is routine in mature deployments (ANSI/ISA-18.2 context, as cited in WorkSync Research Volume IV), and past roughly a dozen items a queue stops functioning as a work list. That is why span of control expands with the ranking layer rather than with the detection layer: once the queue is rationalized, scored, and sequenced, the same person spends the day on the items that carry the value instead of triaging a list. Any specific well-per-person figure depends on well density, drive times, failure rates, and instrumentation coverage, so it is worth measuring on your own field rather than adopting from someone else.