Exception Handling: Where Planners Actually Spend Their Day

Planning systems are built around the transaction that goes as expected, and that transaction needs no human at all. The order is placed, confirmed, shipped, received, and invoiced, and nobody touches it.

What consumes a planner's day is everything else. The supplier confirms a different quantity. The shipment leaves three days late. A container is held for inspection. Quality rejects a batch. A customer moves a delivery date. A part is superseded. A carrier misses a collection. A price changes after the order.

Each of these breaks the assumption the plan was built on, and each requires someone to work out what it means and what to do.

The uncomfortable arithmetic in most operations is that exceptions are a minority of transactions and the overwhelming majority of the effort. A planner might touch a small fraction of orders and spend the whole week on them.

Which reframes where automation should point. The instinct is to automate the routine flow, and that is usually already automated, which is why it is routine. The remaining opportunity is in the exception path, and that path is harder because it involves judgement, incomplete information and consequences.

So the useful question is not how do we automate exception handling. It is which parts of exception handling are mechanical, and which are the judgement that the mechanical parts exist to support.

Every exception, whatever its cause, runs through the same four stages, and they have completely different automation profiles.

Detection. Noticing that something has deviated. Almost entirely mechanical: comparing promised against actual dates, quantities, and locations. The reason this fails in practice is not difficulty but data, which the next step covers.

Assessment. Working out what it means. Does this delay actually matter? That depends on the buffer stock, on whether the customer order it feeds is firm, on the safety stock policy, on whether an alternative source exists. Partly mechanical, because much of it is a calculation over data you hold, and partly not.

Decision. Choosing what to do. Expedite by air at a cost. Partial ship. Substitute. Allocate scarce stock between customers. Tell the customer. Each of these trades money against service against relationship, and the trade-off is rarely written down anywhere.

Communication. Telling the supplier, the customer, the warehouse, the sales team. High volume, repetitive, and the part planners most resent because it is where the hours go.

The automation profile that follows is clear. Detection should be fully automated. Assessment should be automated into a recommendation with its reasoning shown. Decision stays human for anything with cost or customer impact. Communication is drafted and reviewed.

Most tools in this space sell the decision layer and under-deliver, because that is the layer requiring the trade-offs nobody documented. The wins are at the two ends.

Control tower is the marketing term for a system giving end-to-end visibility of a supply chain, and it is worth understanding why these projects so often disappoint.

The promise is a single view: where every order is, which are at risk, what to do about it. The promise is genuinely valuable, because the underlying complaint is real. Most organisations cannot answer where is my order without three people checking three systems.

The reason projects fail is almost never the analytics layer. It is that the data does not exist in the form the dashboard assumes.

Specifically. Supplier commitments live in emails rather than in systems, so there is no structured promised date to compare against. Carrier tracking is patchy, and milestone definitions differ between carriers so events are not comparable. Purchase orders are amended by phone. Part numbers differ between your system and the supplier's. And the actual receipt date recorded is when someone got round to booking it in.

Build a beautiful dashboard on that and you get a confident display of unreliable information, which is worse than no dashboard because people act on it.

Where language tooling genuinely helps is precisely here, and it is unglamorous. A large share of the missing data exists in unstructured form: supplier emails confirming dates, carrier notifications, chat messages. Extracting structured events from that correspondence populates the very fields the visibility layer needs.

So the sequence is: get the events into structured form first, then build the view. Reversing that is why the last generation of these projects underdelivered.

The path a deviation should take, with the automation boundary marked.

An event arrives, either from a system or extracted from correspondence. The first question is mechanical: does this deviate from what was promised. If not, it is noise and it stops here, which matters because most alerting systems fail by firing constantly.

If it deviates, assess impact against data you already hold. Is there buffer? Is the downstream order firm? Does this breach a customer commitment? This produces a severity, and the reasoning behind it should be visible rather than a score.

Low impact and covered by buffer: log it and take no action. Planners currently spend real time on exceptions that did not matter, and suppressing those is a large part of the value.

Material impact routes to a person with the assessment attached, a recommended action and its cost, and a drafted communication ready to send.

The boundary is drawn where money, customers or relationships are affected. Above it, the planner decides. Below it, the system acts and records.

The thing to notice is that the automation is doing the reading, the arithmetic and the drafting, and the planner is doing the judging. That is the same division as every other profession in this catalogue, arrived at from a completely different starting point.

The characteristic way exception management systems fail deserves its own treatment, because it is predictable and it destroys the tool's value permanently.

A system is configured to flag deviations. It flags everything: every order a day early, every quantity variance of one unit, every carrier scan out of sequence. Planners receive hundreds of alerts. They cannot triage them, so they stop reading them. The system now has negative value, because the organisation believes it has exception management and nobody is looking.

That sequence is common enough to plan against from the start.

What prevents it. Alert on impact, not on deviation. A two-day delay on an item with six weeks of cover is not an exception; it is normal variation. The threshold should be derived from buffer and downstream commitment, not from a fixed tolerance.

Suppress what is already known. Ten alerts about one delayed container is one exception.

Measure the action rate. If a category of alert is dismissed without action nine times out of ten, that category is miscalibrated, and this is measurable rather than a matter of opinion.

And give each alert somewhere to go. An alert that does not say what to do, or who owns it, becomes someone else's problem by default.

The deeper point, and it applies to any monitoring system. The objective is not detecting everything. It is that a planner opening the queue finds a small number of things that genuinely need them. A system that surfaces twelve real items a day is worth more than one that surfaces four hundred including all twelve.

A large share of exception work is communicating with suppliers, and it is tempting to automate it entirely. That temptation should be resisted for a reason that is commercial rather than technical.

What makes supplier relationships work is that they are relationships. When you are short of a part and three of your competitors want the same allocation, the supplier decides who gets it, and that decision is influenced by whether you are a customer they want to help. Automated chasing at scale is precisely the behaviour that erodes that.

So the division matters more here than the capability does.

What automates well. Routine confirmations and acknowledgements. Structured data requests, where you need a date or a quantity. Reminders on overdue confirmations. Extracting commitments from supplier replies into your systems, which is the high-value one from the visibility step.

What should not be automated. Escalation, which carries a relationship signal. Negotiation about allocation, price or priority. Anything about performance or a quality problem, which is a conversation. And anything to a supplier you depend on and cannot easily replace, where the relationship is a strategic asset.

A practical test that works. If you would be comfortable with the supplier knowing this message was generated and sent without a person reading it, automate it. If knowing that would change how they feel about you, do not.

That test happens to be a reasonable general rule for automated communication in any commercial relationship, and it captures more than a list of allowed message types would.

A framing worth correcting, because a lot of money is spent on the wrong side of it.

After any significant disruption, the response is usually to invest in prediction: risk monitoring, supplier risk scores, early warning systems. The appeal is obvious. If you had known earlier, you could have acted.

The difficulty is that the disruptions which cause the most damage are the ones prediction handles worst. They are rare, so there is little data to learn from. They are novel, so the past is a poor guide. And the ones that matter most are frequently correlated across suppliers in ways a supplier-by-supplier risk score does not capture: a region, a shared sub-tier supplier, a single component everyone depends on.

What actually produces resilience is structural and mostly known already. Dual sourcing on critical items. Inventory positioned where it buys the most time. Shorter lead times, which shrink the exposure window. Knowing your supply chain below the first tier, which most organisations do not. And qualified alternatives, ready before you need them.

Each of those costs money and reduces efficiency, which is why they lose arguments in normal times.

Where assistance genuinely contributes. Mapping the chain below tier one from documents and correspondence you already hold, which is a reading problem at a scale nobody has done manually. Monitoring news and notifications against that map, so an event names the affected parts. And keeping the map current.

That is real value, and note what it is: better information about structure you can act on, rather than a prediction of what will happen.

Pulling the cursus together into what someone working in this field should take away.

The biggest available wins are in documents, not in forecasting. Extraction from invoices, packing lists, transport documents and supplier correspondence removes re-keying, catches discrepancies nobody was checking, and populates the visibility layer that dashboards assumed existed. It is mature, it is measurable, and it does not touch a single decision.

Forecasting improvements are usually smaller than promised, because the binding constraint is typically process or structure rather than the model. Measure forecast value added before buying anything, and remember that the bullwhip effect is not a forecasting failure and cannot be fixed by forecasting.

The decisions carrying real exposure are narrow and identifiable: tariff classification, origin, sanctions screening, and any statement made to a customs authority. Those get assistance in finding candidates and a human applying the rules, with a recorded reason.

Exception handling is where the hours actually are, and the win is suppressing what does not matter as much as it is handling what does. Alert on impact, not deviation.

And the relationships stay human, because in a shortage the allocation goes to the customer the supplier wants to help.

The unifying observation: almost nothing in this field is limited by the sophistication of the model. It is limited by whether the information exists in usable form, and by whether the process and incentives around the decision are sound. Both of those were true before any of these tools, which is why the tools help most where they turn documents into data.