How to stop an automation that still has work to do
Retire intake, accepted jobs and external authority in a deliberate order, so a late event cannot revive an obsolete process.
Automation7 min read
Who has time for the exception queue?
Thirty daily exceptions and eighteen review slots create a growing backlog. A worked capacity ledger shows what it takes to recover before waiting changes the job.
Thirty cases arrive, eighteen cases leave
Thirty orders arrive for review. A colleague has ninety minutes and each takes five, so eighteen can leave the queue. The dashboard may give all thirty a clear status and a named owner; there are still twelve more orders than the available time can cover. Tomorrow those twelve will be waiting alongside another thirty. The backlog starts in the ordinary plan, before anything unusually difficult has happened.
An exception queue is often described as a safety feature. It is one, provided the business can actually perform the work it collects. Otherwise the system can turn a manageable interruption into a growing inventory of customer promises nobody has time to finish. The person assigned to the queue becomes the place where an incomplete automation meets a full working day.
Use those assigned numbers for a small planning exercise: thirty daily arrivals, eighteen completed reviews, five minutes per review and an empty queue at the start. They are not a staffing recommendation or client results. They let us ask a question a named owner cannot answer alone: how much of the work will still be waiting when that person’s ninety minutes are over, and what must change to finish it?
Amazon's discussion of queue backlogs distinguishes accepting work reliably from completing it promptly, and considers recovery capacity alongside ordinary throughput.[1] That distinction applies when a person consumes the queue too. Durably recording every order preserves the obligation, but the recovery plan still has to account for how much active review fits in the ninety minutes available and what happens to work carried forward.
Give accumulated work a place in the calculation
The first day closes with twelve cases: thirty arrivals minus eighteen completions. On day two those twelve join another thirty arrivals, and eighteen completions leave twenty-four. The following closing backlogs are thirty-six, forty-eight and sixty. At these fixed rates, twelve cases accumulate every working day, so the increasing backlog follows from the normal operating assumptions rather than an exceptional burst of difficult orders.
Write the recurrence plainly: closing backlog equals the greater of zero and opening backlog plus arrivals minus completed capacity. Include unresolved cases carried from yesterday. A report showing only today's completed reviews can make an overloaded process look productive while concealing that waiting work increases faster. Eighteen completed cases are useful, but they answer a different question from whether the business is catching up.
The handling-time assumption needs inspection in a real process. A two-minute address correction and a supplier dispute requiring several messages are not equivalent units. Separate waiting for information from active review time, and track how many cases reopen after a supposed resolution. If the same item is counted as three fresh cases, the intake metric will obscure the cause and consume more apparent capacity than the business task actually needs.
Keep the original order identity and arrival time when a case is retried. Otherwise every fresh attempt can give an old customer promise a new-looking age. The reviewer needs to see the history, the current blocker and the deadline that matters to the order. The capacity calculation needs arrivals, completed outcomes and reopened work counted consistently. A queue of technical messages can be busy without showing how much customer work remains unfinished.
Stopping growth does not clear yesterday
After five days, sixty cases are waiting. A better screen cuts review time from five minutes to three, so the same ninety-minute block now handles thirty. That is a worthwhile improvement: the queue stops growing. It also leaves the original sixty exactly where they were. A faster screen has caught up with the day’s arrivals, and we still need spare capacity before yesterday’s work can go anywhere.
Alternatively, reduce new exceptions to fifteen per day while retaining eighteen reviews. The spare capacity is three cases daily, so clearing sixty takes twenty working days under the fixed-rate assumptions. That is a long tail for a fix which might otherwise be announced as a successful fifty-per-cent reduction in new exceptions. The relative improvement and the absolute recovery time are both worth reporting.
Add a second ninety-minute review block instead, keeping five-minute handling and thirty arrivals. Thirty-six cases can be completed, giving six daily slots for the backlog; sixty then takes ten working days to clear. Neither option is free. One depends on a genuine upstream reduction, the other uses time that belonged to other work. Changing the assumptions is a proposal to examine, not permission to assume the improvement has already happened.
The table lets the team compare those recovery plans without losing tomorrow’s arrivals from the calculation. If there is no spare capacity, catch-up remains a hope rather than a date. Work backwards from the recovery window the business needs and examine what source repairs, staffing, eligibility or tooling could supply. Prioritising an urgent order can protect its deadline; rearranging the queue cannot create the additional review time the rest of the plan needs.
What clears the sixty cases already waiting?
Illustrative fixed-rate planning after five working days. The initial process receives 30 cases and can review 18 daily, so 12 more wait each day and 60 are left after day 5.
Scroll sideways to see all columns.
| Changed assumption | Daily arrivals / capacity | Backlog change | Days to clear 60 |
|---|---|---|---|
| No change | 30 / 18 | Grows by 12 | Never under these rates |
| Review takes 3 min instead of 5 | 30 / 30 | No change | Existing 60 remain |
| Upstream exceptions fall to 15 | 15 / 18 | Drains 3 per day | 20 working days |
| Review time rises to 180 min | 30 / 36 | Drains 6 per day | 10 working days |
A waiting order can become a different problem
Add one explicit rule to the example: an order's stock reservation expires four hours after intake. Thirty exceptional orders arrive at 09:00, and the only review block runs from 09:30 to 11:00. Eighteen can be handled in that block; twelve cannot. Their reservations expire at 13:00 if nothing else changes. Opening those cases tomorrow is no longer simply a matter of resuming yesterday's fulfilment step.
At 13:00 the unresolved orders lose their reservations. A reviewer returning tomorrow now needs current stock and the options still available to the customer. The old reference may fail; a new reservation may find no stock. The Retry button has kept its label while the job behind it has changed. Show the expiry and the required next action so the colleague does not unknowingly resume a fulfilment step that is no longer possible.
In this situation, age-based priority and deadline-based priority can disagree. The oldest low-consequence case might wait while a newer order approaches its reservation deadline. Make that decision visible. A priority reason should explain the consequence being protected, and lower-priority work still needs a bounded route to attention. Repeatedly choosing fresh urgent items can leave the same older customers waiting through every improvement.
Do not respond by silently dropping accepted orders when the queue is full. Admission decisions need an honest business contract: perhaps restrict which new orders are eligible for automatic acceptance, request missing information earlier or give a truthful delay before committing. Systems differ in what work can be deferred or rejected; Amazon's backlog discussion explicitly explores workload-dependent choices.[1] For a paid order, losing the queue item is not the same thing as resolving the customer obligation.
The reservation expires before the queue is cleared
An illustrative thirty-order intake with a four-hour stock reservation and one ninety-minute review block.
- 09:0030 exceptional orders arrive
Reservations expire at 13:00
- 09:30–11:0018 five-minute reviews fit
12 orders remain unresolved
- 13:00Remaining reservations expire
Recheck stock and customer options before fulfilment
Decide which work should never have reached the queue
Group new cases by the decision the reviewer makes. If most reviews only copy a delivery code from a field the intake form already holds, repair that handover. If a missing field causes repeated supplier contact, improve the request for information. If the ambiguity is genuine and consequential, preserve the review rather than optimise it away merely because it is difficult to schedule.
Measure the effect where it occurs. A faster screen should reduce active handling without removing the evidence needed for a good decision. An upstream validation change should reduce the relevant arrival category without simply rejecting legitimate requests into an invisible email thread. The queue can look healthier because work moved elsewhere, so keep the alternative route in the accounting.
For a small team, a weekly capacity ledger can be modest: opening unresolved cases, new cases, completed outcomes, reopened cases and closing unresolved work, split by meaningful category. Add oldest business age and approaching deadlines. Attach the assumptions behind any catch-up date. A colleague should be able to see whether the plan includes tomorrow's new work, not discover that omission after donating another afternoon to recovery.
I would keep the capacity ledger beside the exception dashboard. The dashboard helps someone work a case; the ledger shows whether that work can finish within the customer deadlines. Include the older cases as well as new arrivals when comparing an upstream repair, extra review time or a different acceptance rule. Then a proposed catch-up date can be explained in available hours and specific commitments, rather than in how orderly the queue now looks.
Working on a workflow like this? Hamsa helps finance and operations teams connect their tools and handle the exceptions, starting with one workflow.
See the Payment Operations PilotReferences & further reading
Primary sources behind this article. Living documentation may change.
- David Yanacek: Avoiding insurmountable queue backlogs, Amazon Builders’ Library Published 5 December 2019
Practical engineering. A human perspective.
More about Hamsa Software and the person behind it. Editorial notes.A few more things
worth a read.
Back to the reading room 
A budget that three workers can share
Enforce task limits through atomic reservations and repeat-safe settlement, including the uncomfortable case where a timed-out operation may still be spending.
What exactly did that approval authorise?
Bind an assistant’s approval to the action, target and material revision, then enforce that binding when the write happens.