A held order, an incomplete delivery, a replacement, a return or a cancellation handled as a case with a named owner, an authorized decision and confirmation of what was actually carried out.
01 · The problem
The exception shows up at two moments. Before dispatch, the order is held: the product ordered is out of stock, the order is on credit hold, the store's receiving window has already closed, or the dispatch paperwork is incomplete. After dispatch, the delivery does not go as ordered: pallets are missing, goods arrive damaged, the customer rejects part of the load at their dock, the truck arrives outside the window, or delivery fails because of an address issue.
From there the response fragments across teams. Customer service promises an answer, order management works out what is still outstanding, the distribution center has the record of what left the site, transport waits on the carrier, and the commercial team finds out when the customer calls again. Each team works from whatever information it managed to gather, the promise made to the customer sits in no system of record, and the original order stops being the common reference.
Coordination runs on whatever is already to hand: Microsoft Excel spreadsheets listing the day's flagged orders, email and messaging apps to chase the carrier for a copy of the signed delivery note, phone calls to the distribution center, and Power BI reporting on the month's service level. Each of these does a useful job, and none of them leaves a record of what was promised to the customer, who authorized the replacement and what was actually carried out.
At the end of the day the useful question is not what happened to the truck, but what was resolved, who authorized it and what the customer actually received.
02 · The solution
Every exception is handled as a case with a defined workflow: intake of the alert — from the customer, the distribution center, the carrier or the review of held orders — classification of the reason, a side-by-side comparison of what was ordered and what was delivered, an authorized operational decision in line with the applicable rule, execution by whoever carries it out, and confirmation of what was actually done.
The case never starts from a blank form: the order arrives with its context already declared in the Operational Graph — the customer and the agreed delivery terms, the dispatch and its delivery note, the distribution center that built the load, the carrier and the assigned route, the product and its batch where that applies, and earlier exceptions for the same customer or the same lane. BPMflow orchestrates the workflow over that context — cases, assignment, deadlines, authorizations and evidence — rather than over a diagram of its own.
Illustrative example. A customer receives six of the eight pallets on the order and deducts the shortfall from their next payment. These are two cases with two closures: here the decision is whether the missing pallets are reshipped, rescheduled or cancelled, and that decision is confirmed; the monetary difference is settled in Trade Claims and Deductions. Reshipping the goods does not settle the claim, and settling the claim does not complete the delivery: each case closes on its own, and both share the same order as their reference.
When the discussion moves to the service level agreed with the logistics operator, the contractual context comes from Vendor, SLA & Contract Intelligence. If the incident also results in a disputed supplier invoice — a freight charge that was never agreed, for instance — that path is Invoice Exception Resolution.
03 · Capabilities
Exceptions sit in a single queue, with the reason, the customer, the affected order, its age, the outstanding promise and any pending authorization all in plain view. Max answers questions about the case within the authorized context: it explains what is still missing and shows the evidence on record, along with how earlier exceptions for the same reason ended.
Opens the case from a customer complaint, a distribution center alert, a carrier report or the daily review of held orders.
Classifies the case as an order held before dispatch, a shortfall, damage, the wrong product, rejection at the customer's dock, delivery outside the agreed window or an undeliverable address: each reason carries its own owner, its own deadline and its own valid outcomes.
Brings together the order, the dispatch note, the signed delivery document and the evidence supplied by the warehouse or by transport, so that what was ordered and what arrived are both on the record.
Reschedule, reship the missing goods, substitute an equivalent, accept the partial delivery, authorize the return or cancel: the outcome is chosen and authorized based on the reason, the customer and the amount at stake.
Records what was promised to the customer and by when, and keeps any case handed to the carrier or to the distribution center visible with its deadline. The carrier takes part through scoped access to its own case.
Captures confirmation from the responsible system or from the authorized owner, whichever was agreed for that event, and keeps on file what was decided, who authorized it and what the customer received.
04 · Roles
Owns the customer relationship and the promise made.
What they see
The open exceptions on their accounts, with the reason, the affected order, the outstanding promise and the deadline.
What they do
Opens or confirms the case, agrees a workable outcome with the customer, and records their acceptance or their objection.
Takes the case through to a confirmed outcome.
What they see
Held orders and short deliveries, showing what was ordered, what was dispatched and what is still outstanding.
What they do
Classifies the reason, coordinates the reschedule, the substitution or the return, and follows the case through to its confirmation.
Supplies what actually happened in the warehouse and on the road.
What they see
The cases on their site and their routes, with the load detail, the delivery document and the carrier response.
What they do
Chases and supplies the carrier evidence, confirms what left and what came back, and books the pickup or the new delivery.
Signs off the outcome when it affects the customer agreement.
What they see
The exceptions waiting at their level, with the reason, the proposed outcome and the amount at stake.
What they do
Approves or rejects the proposed substitution, return or cancellation, or sends the case back with comments, in line with the applicable authorization rule.
05 · Implementation
Implementation is assisted and starts from the operation as it runs today: the minimum context around the first exception reason is enough, with no architecture project up front.
1 · Agree on the outcome
Which exception reasons are in scope, which outcomes each one allows, who authorizes by customer and by amount, and what confirms that the resolution was actually carried out.
2 · Gather the context, connect the systems
Pulls the order, the dispatch note, the delivery status and the agreed service terms from the ERP, the order management system and the transport system, and adds the organization's document repository where the signed delivery documents are kept.
3 · Pilot it, then hand it over
The workflow is piloted on the exceptions open that week; reasons, deadlines and authorization levels are then tuned, and the client team takes over daily operation.
06 · Typical scenarios
Several distribution centers, subcontracted transport, customers with their own receiving rules and tight delivery windows: the setting in which these reasons keep recurring.
An order exception is closed when someone decides what the customer receives, someone authorizes it, and the result is confirmed. The practical way in is one reason and one distribution center.
Order and Logistics Exceptions is an EAFlow cross-industry solution on the Operational Graph, supported by BPMflow's automation capabilities. It coordinates operational recovery when an order or delivery goes wrong; the monetary difference the same incident may leave open is handled through Trade Claims and Deductions. The reasons, outcomes and scenarios on this page are illustrative: rules, authorization levels and confirmation sources are configured with each organization.
