Automating delivery exceptions in logistics: what AI can handle and what stays with your team

A late shipment is not really the problem. The problem is what happens in the hour after: who reads the carrier email, who checks the order, who decides on a credit, and who retypes the same update into three systems by hand. Most operations teams handle delivery exceptions through a shared inbox, a spreadsheet and whoever answers the phone first, which works until volume passes what a person can triage. Then it breaks the same way every time: routine exceptions eat the time the serious ones need.

What counts as a delivery exception?

A delivery exception is any shipment event that departs from the plan the order was built on. In most logistics operations, that falls into a short list of repeat categories.

• Failed delivery attempts, when nobody was available, the dock was closed, or access needed a code nobody sent ahead.
• Address issues, from an incomplete suite number to a location the carrier's system cannot resolve.
• Damage, found at delivery or reported after, usually needing photos and a description of what changed in transit.
• Shortages and overages, where the piece count or weight on the proof of delivery does not match the bill of lading.
• Refused shipments, where the consignee declines the freight at the door, often over price or condition.
• Missed appointment windows, especially for scheduled or white glove deliveries expecting a specific time.
• Customs holds, on cross border freight waiting on documentation, classification or inspection.
• Proof of delivery disputes, where the customer says a shipment never arrived and the carrier's signature or photo says otherwise.

None of these are rare. They are the ordinary cost of moving freight through a network of docks, drivers and handoffs, which is why the goal is not to eliminate them. It is to shrink the time between the event and the right person acting on it.

Where do the exception signals come from?

Exception information rarely arrives in one place. A single failed delivery can generate a carrier tracking event, an email from the carrier's exceptions desk, a driver app note, a photo at the door and a customer call, often disagreeing on the reason.

The most structured signal is the carrier's own status feed. Carriers that support electronic data interchange send an EDI 214, the transportation carrier shipment status message, reporting pickup, in transit, arrival, delivery and exception events with a timestamp, location and reason code, sent directly from the carrier's system to the shipper's (SPS Commerce).

Carriers that do not exchange EDI still publish tracking events through a portal or an API, most flagging exceptions in plain language rather than a code. One LTL carrier's own tracking tool, for example, surfaces exceptions such as a pickup attempted with no freight available, shown in a banner separate from routine progress updates (Estes Express).

Below the carrier feed sits everything less structured: emails from a carrier's claims desk, forwarded customer messages, photos and signatures from a driver app, and free text notes from whoever answered the phone. This is the layer document intelligence and email reading were built for: the facts are usually present, just not sitting in a field a system can use.

Which systems hold the pieces?

Delivery exception handling touches more systems than any one team owns, which is why it stays manual.

An exception that sounds simple, a shipment marked delivered that the customer says never arrived, needs the TMS milestone history, WMS outbound detail, ERP order and the carrier's proof of delivery image before anyone can answer it, which is the real cost of a single case.

What can automation and AI actually do with an exception?

The realistic scope for automation is everything before the decision, not the decision itself.

A workflow can watch the carrier feed and the shared inbox, read an unstructured email or scanned notice, and classify the exception. It can then pull the order, shipment history and customer account from the TMS, WMS and ERP, so the full picture exists before a person opens the case. For routine exceptions it can draft the customer update in plain language, referencing the actual order and a revised date. For a damage claim it can open the claim record and attach the documents carriers require: the bill of lading, proof of delivery and photos. Finally, it can route the case to the operator who owns that lane, carrier or account, with a deadline, instead of leaving it in a shared queue until someone notices.

None of this requires deciding who is at fault or what a customer is owed. It requires being fast, consistent and honest about what it does not know, routing anything ambiguous to a person rather than guessing.

What should stay with your team?

Four kinds of decision belong with a named person, not a workflow.

Claims decisions. Whether a claim is valid, and how much the carrier or your own operation should absorb, is a liability judgment a workflow should prepare for, not make.

Credits and refunds. Any adjustment to what a customer owes or is owed is a financial decision, following the same approval path a manual credit would.

Customer escalations. A frustrated or high value customer needs a person who can make a commitment, not a templated update.

Carrier disputes. Pushing back on a carrier's account of what happened, especially where money is involved, needs someone who understands the account relationship.

The table below applies that split to the most common exception types.

Illustrative example: Consider a regional distributor shipping mixed pallet freight through five core carriers. Today, a failed delivery generates a carrier email that sits in a shared inbox for hours before anyone replies to the customer. A workflow reads the exception email as it arrives, matches it to the order in the TMS, and classifies it as a failed delivery attempt caused by a closed dock. It drafts a customer message with the real order number and two reschedule windows pulled from the carrier's available slots, then routes the case to the account's regional coordinator with a two hour deadline. The coordinator reviews the message, adjusts the offered window and sends it. The distributor has not removed a person from the decision. It has removed the forty minutes that person used to spend finding the order and the carrier's contact details before writing a single sentence.

How do you know it is working?

Four measures matter more than a general accuracy score, because they describe what the customer and the business actually feel.

Time to first action shows how long an exception sits before anyone, human or workflow, acts on it, usually the biggest early win since assembling context is where today's time goes.

Exceptions resolved within the promised window measures whether your team keeps the commitment made in the first customer update.

Customer contacts per exception counts how many times a customer calls or emails about the same issue. A falling number means the first update answered their question.

Claims recovered tracks how much of what a carrier owes you is actually collected, since unfiled or unfollowed claims are money left behind. One LTL carrier's own policy allows up to 30 days to conclude a claim after acknowledging it within 10, with a 5 day window to report concealed damage (Estes Express), exactly the deadline a workflow can track on its own.

Missed appointment windows compound quickly. Drivers reported being detained in 39.3 percent of stops in 2023, costing 3.6 billion dollars in direct charges and 11.5 billion dollars in lost productivity industry wide (American Transportation Research Institute). Much of that surfaces as a missed window on the receiving end, which a workflow can flag the moment a TMS milestone slips.

How do you start with one exception type?

Do not automate delivery exceptions in general. Pick one exception type, on one carrier or lane, and prove it before expanding.

1. Pick the highest volume, lowest judgment exception type, usually a failed delivery attempt or a proof of delivery dispute rather than a damage claim.
2. Map where the signal actually arrives today, a specific inbox, a carrier portal, an EDI feed, or all three, and decide which one is authoritative when they disagree.
3. Agree what a drafted response needs to include before the team will trust it, with the operator who owns these exceptions today.
4. Set the routing rule and the deadline, and name the person or role each exception lands with, not a shared queue.
5. Run it alongside the current process for a defined period and compare results against the baseline.
6. Add the next exception type only once the first is running with minimal correction.

Which business processes to automate first applies the same scoring approach to any candidate process, and AI document processing for invoices, contracts and forms goes deeper on reading the bills of lading, packing lists and proof of delivery documents this work depends on.

How Kastling approaches delivery exception automation

Kastling treats delivery exception handling as one workflow to understand before anything is built, as part of the AI Integration and Automation service. That starts with a discovery call, and a separately scoped paid audit is common next, reviewing the carriers, systems and exception volumes involved before recommending where to start.

In delivery, exception routing and document checks work the way the process already does: shipping documents compared field by field, issues sent to the operator accountable for the lane or account rather than a shared inbox. Claims decisions, credits and carrier disputes stay with a named person, and we agree up front how success will be measured. Logistics covers where this fits alongside other shipping and freight workflows.