The Exception Queue: Why Supply Chain Ops Breaks Before It Scales

Every supply chain team has a queue nobody puts on the org chart.

It has no owner, no SLA, and no line in the budget. It is the running list of things that did not go to plan: the purchase order acknowledgement that never came back, the short-shipped pallet, the reefer that drifted two degrees outside spec somewhere between Rotterdam and Singapore, the invoice that does not match the receipt that does not match the PO. Nobody hires for it. Everybody works in it.

Ask an operations director where their senior people spend their week and you will rarely hear "network design" or "supplier strategy." You will hear chasing. The exception queue is where operational capacity quietly goes to die, and it is the single clearest place to see why supply chain teams break before they scale.

Exceptions do not scale linearly

The uncomfortable arithmetic of operations is that volume grows in a straight line and exceptions do not.

Add a second distribution centre and you have not doubled your exceptions — you have added handoffs between two sites, a new carrier mix, a second set of local compliance quirks, and a fresh category of failure that exists only in the seam between them. Add a marketplace channel, a new jurisdiction, a language, a customs regime, and the same thing happens again. Each addition multiplies the number of places where reality can diverge from the plan.

This is why headcount never quite catches up. A team sized for last year's throughput is structurally under-sized for this year's exception volume, even when unit volume looks manageable. The gap does not show up as a missed target at first. It shows up as senior people doing junior work, escalations sitting a day longer than they should, and a slow erosion of the judgement capacity the business actually pays them for.

The market has noticed. Gartner expects 40% of enterprise applications to ship with task-specific AI agents by the end of 2026, up from under 5% a year earlier, and "exception-handling and disruption agents" now exists as a named category rather than a forward-looking idea. The exception queue has become the first place most operators point automation at, because it is the most obviously broken thing they own.

The four unsatisfying options

Most mid-market operators end up choosing between four unsatisfying answers.

Hire into it. A mid-level supply chain coordinator in most markets runs $90K–$160K fully loaded. The requisition takes three to six months to fill, then two to four more to ramp — and in that window the exception queue has grown again. You are hiring for the volume you had when you wrote the job description.

Absorb it. Push the queue onto the team you already have. This works for a quarter. Then your best people are spending their days on PO chasing and temperature-excursion paperwork, your strategic projects slip, and the person you least want to lose starts taking recruiter calls.

Automate it with tooling. Rules engines and alerting are genuinely useful and genuinely insufficient. They are excellent at telling you an exception exists. They are poor at deciding what to do about it when the rule does not cleanly apply — which is the definition of an exception. A tool that flags 400 anomalies and resolves none has moved the work, not removed it.

Hand it to an autonomous agent. This is the 2026 answer, and it is materially better than alerting. Early adopters report 60–75% cycle-time reductions on purchase order processing and invoice matching, roughly three-quarters of POs clearing without a human touch inside six months, and exception-handling accuracy in the high eighties after ninety days in production. Those numbers are real and deserve to be taken seriously.

But read the failure rate rather than the success rate. High-eighties accuracy means more than one call in ten is wrong, and exceptions are not a domain where wrong calls distribute themselves evenly. The routine ones resolve correctly. The ones that go wrong are disproportionately the novel, ambiguous, consequential cases — the substitution from a long-standing supplier, the excursion that might be a sensor artefact, the discrepancy pattern that is actually a vendor conversation. An agent with delegated authority and no expert above it will act confidently on precisely the cases where confidence is least warranted.

None of these is stupid. They are all rational responses to a structural mismatch. The problem is that all four treat exception handling as either pure labour or pure automation, when it is neither.

Exceptions are two jobs wearing one coat

Look closely at any exception and it splits cleanly in two.

There is the throughput half: gathering the shipment record, pulling the carrier's event history, reconciling the three-way match, drafting the claim packet, chasing the acknowledgement, logging the corrective action, keeping the audit trail intact. This work is high-volume, structured, repeatable, and largely rule-bound. It is also where the hours go.

Then there is the judgement half: deciding whether a two-degree excursion actually compromised the load or was a sensor artefact. Deciding whether to accept a substitution from a supplier who has been reliable for six years. Deciding when a pattern of small discrepancies stops being noise and becomes a conversation with the vendor. This work is low-volume, high-consequence, and depends on domain experience that cannot be written into a rule.

The two halves have almost nothing in common except that, today, the same person does both. That is the design flaw. You are paying senior-hire rates for a role that is 80% structured throughput, and then getting a compromised version of the 20% you actually needed, because the person doing it is tired and behind.

Splitting the queue

The h.work model separates those two halves and staffs them differently.

An AI Specialist owns the throughput. Not a chatbot bolted onto your stack — a named, role-specific worker deployed into the channels and systems your team already uses: Slack, Teams, email, WhatsApp, your ERP, your carrier portals. Aarav, our cold chain and shipment coordinator, monitors reefer loads, catches temperature excursions as they happen, and assembles the carrier, customer, and claims response. Aiko, an account service coordinator, owns order flow, deductions, fill-rate exceptions, EDI, and PO acknowledgement follow-up. They work continuously, they do not batch overnight, and every action they take is logged and auditable.

A credentialed human expert owns the judgement. Consequential calls route to a senior domain practitioner — identity-verified and credentialed through Humanity — before anything executes. Routine work stays under continuous monitoring. When the expert corrects a call, that correction becomes ground truth: the Specialist handles the same situation better next time, which means the expert's attention is spent on genuinely new problems rather than the same problem forty times.

Because one expert can supervise Specialists serving 10–30 companies, the economics work in a way that a dedicated internal hire cannot match. The result lands at 20–40% of fully loaded hire cost, deployable in around 24 hours rather than in two or three quarters.

The question auditors are about to start asking

The governance conversation has moved faster than most deployment plans. Bounded autonomy, delegated authority, escalation thresholds and decision governance are standard vocabulary now, and under the EU AI Act the expectation is explicit: audit logs and meaningful human override for agents making operational decisions. The question is no longer whether an agent resolved the exception. It is who is accountable for the call, under which policy, with what record.

Most agentic deployments answer that with a log file. A log file tells you which model version fired and what parameters it was given. It does not give your auditor, your customer or your insurer a person who stands behind the decision.

Splitting the queue answers it properly. Throughput actions are logged and traceable, as you would expect. Consequential actions carry a named, identity-verified, credentialed human who reviewed and approved them. That is not a compliance layer bolted onto an automation project — it is the same structural split that makes the operating model work, seen from the auditor's side of the desk. Building override and accountability in afterwards costs considerably more than designing it in now.

What changes on the ground

The visible change is not that exceptions disappear. Exceptions are a permanent feature of moving physical goods through an imperfect world. The change is where they land and how long they sit.

Your senior people stop being the queue. They become the escalation path — reviewing the calls that genuinely need a decade of experience, and leaving the assembly, chasing, and documentation to a worker built for it. The queue drains continuously instead of in Monday-morning bursts. And when your auditor, your customer, or your board asks who reviewed a consequential decision, there is a name and a credential attached, not a shrug.

Artificial intelligence handles the throughput. Human intelligence handles the judgement. In supply chain operations, that line is unusually easy to draw — which makes it an unusually good place to start.

The common advice this year is to pick the exception queue that hurts most and watch event-to-action time collapse. Sound advice, with one amendment: decide who owns the calls that should not collapse automatically before you point anything at the queue.

If your exception queue is growing faster than your headcount plan, the queue is telling you something about the shape of the role, not the size of the team.

Browse the supply chain and logistics Specialist roster at h.work, or interview one before you deploy.