Proactive shipment exception management: catch the delay before the customer calls

What counts as a shipment exception

A shipment exception is any event that puts a shipment off its plan: off the date, the route, the documents, or the condition someone was promised. A status update tells you where a shipment is. An exception tells you that where it is no longer matches what was agreed.

• ETA slip the vessel, flight, or truck now arrives after the date promised to the customer or the production line.
• Missed pickup or milestone no pickup, gate-in, loading, or departure event when the plan says there should be one.
• Rolled or cancelled booking the carrier moves the container to a later sailing or cancels the booking.
• Customs hold held for inspection, missing or inconsistent documents, or unpaid duties.
• Document discrepancy commercial invoice, packing list, and bill of lading disagree with each other or with the order.
• Damage or OS&D goods arrive over, short, or damaged.
• Failed delivery the consignee is closed, the address is wrong, or the delivery is refused.
• Detention and demurrage risk a container is close to the end of its free time at the port or with the consignee.

Reactive versus proactive exception handling

In reactive exception handling, an exception is found when someone asks: the customer emails, the warehouse calls, or the weekly report shows a late delivery. By then the team is explaining a problem rather than solving it.

In proactive exception handling, an exception is found from the first signal that something moved. Its impact on the order is checked straight away, and the next step is prepared while there is still time to re-book, expedite, re-plan production, or warn the customer on your own terms.

The difference is not a tool. It is time to awareness: the hours or days between the moment the information exists and the moment the person who owns the shipment knows about it.

Why exceptions are found late

• Signals are spread out. Carrier APIs, EDI status messages (214 for road, 315 for ocean), forwarder emails, port and terminal portals, and vessel tracking each hold part of the picture. Nobody watches all of them for every shipment.
• Statuses are not exceptions. A tracking feed reports that an ETA changed. Whether that matters depends on the order behind it: the promised date, the customer, and the stock on hand. That comparison usually happens in someone’s head.
• Volume hides the few that matter. When most shipments are on time, checking them one by one is mostly confirming that nothing happened. Coordinators learn to skim, and the real exception looks like the others.
• Ownership is unclear. Operations sees the delay, customer service gets the complaint, and planning feels the impact. Without a named owner per account or lane, everyone assumes someone else has it.

A proactive process in five steps

1. Define exceptions against promises, not statuses. Write down what counts as an exception for each customer segment or lane: for example, an ETA past the promised date, or a missed departure more than six hours after plan. Thresholds belong to your team and should differ by priority.
2. Bring every signal into one timeline per shipment. Collect carrier and forwarder updates, EDI messages, portal statuses, and the emails that carry the real news. Match each one to the shipment and the order it serves, so a change is seen in context rather than in a separate inbox.
3. Check the impact on the order. For each exception, look up the customer, the priority, the promised date, the stock cover, and the alternatives still open. A two-day slip on a replenishment order with three weeks of stock is not the same event as a two-day slip on a line-down part.
4. Route it to an owner with the next step prepared. The account owner should receive the exception with its evidence and a drafted next step: a customer update, a re-booking option, or a request for the missing document. Anything that costs money, such as expediting or re-booking, waits for their approval.
5. Close the loop and learn from it. Record how each exception was resolved and why it happened. A weekly look at exceptions by carrier, lane, and cause shows where the same problem keeps coming back.

What to automate and what to keep with people

The collecting, matching, comparing, and drafting are repetitive and well suited to software. The decisions that cost money or affect a relationship are not.

• Automate: gathering status updates, matching them to orders, detecting exceptions against your thresholds, assembling the evidence, drafting customer updates, and reminding owners of open exceptions.
• Keep with people: whether to pay for expediting, what to tell a key account, negotiations with carriers, claims for damage, and any change to the thresholds themselves.

Where AI fits, and where a rule is enough

Many exceptions can be caught with plain rules: a milestone not reported by a fixed time, or an ETA later than the promised date. If your data is structured and your rules are clear, a rule is cheaper and easier to trust.

AI earns its place where the information is unstructured or the judgement depends on context: reading a forwarder’s email that says a container was rolled, classifying a free-text portal note, weighing the impact of a delay against the order and the customer, and drafting a clear update. The thresholds, permissions, and approvals stay in code your team controls.

How to measure it

• Time to awareness: from the first signal to the owner knowing about the exception.
• Caught first: the share of exceptions raised before the customer asked.
• Checking time: coordinator hours spent on manual status checks each week.
• Repeat exceptions: the same cause on the same lane or carrier, month over month.

Measure a baseline for two weeks before changing anything. Without it, an improvement is a feeling, not a number.

Where to start

• Pick one lane, customer segment, or mode rather than the whole network.
• List the three exception types that cost you the most money or customer goodwill.
• Check which of their signals you can already reach by API, EDI, or email.
• Name an owner for each account or lane in that scope.
• Measure the baseline, then automate the collecting and matching first.