AI for LTL exceptions: missed pickups, reweighs and reclasses

Why LTL exceptions suit AI agents#

LTL exceptions suit AI agents because they are frequent, rule-bound and scattered across email, carrier portals and invoices. A missed pickup, a reweigh or a reclass each follows a recognizable pattern: detect the problem, gather evidence, contact the right party and record the outcome.

The hard part is rarely the conversation. It is having the evidence in one place: the bill of lading, the pickup confirmation, the shipper's scale weight, the dimensions, the photos and the carrier's inspection record. Where those live in several systems and a shared inbox, an agent spends its time asking people to find them.

Most teams start with the agent assembling evidence and recommending an action while an analyst approves it. Exceptions involve money and carrier relationships, and an automated dispute that ignores a carrier's own tariff rules costs goodwill that takes a long time to rebuild.

Playbook 1: missed pickups#

A missed pickup playbook has the agent spot loads with no pickup event after the window closes, confirm status with the shipper's dock, rebook with the same or an alternate carrier, and update the customer. The value is speed plus a clean reason code, so the same failure can be traced and fixed later.

The agent needs these records to do it without a human chasing details:

• 1Pickup request with confirmation number, ready time and dock close time.
• 2Carrier pickup events, including attempted pickups and driver notes.
• 3Dock contact details and any shipper notes about readiness or loading problems.
• 4Rebook history: new carrier, new pickup date and any added cost.
• 5Customer notifications sent and when they went out.
• 6A reason code from an agreed list: carrier miss, shipper not ready, dock closed, wrong address.

Playbook 2: reweighs#

A reweigh playbook has the agent match a corrected carrier invoice to the declared weight on the bill of lading, request the carrier's weight inspection certificate, compare it with the shipper's own scale records and recommend whether to dispute. Carriers set dispute procedures and deadlines in their tariffs, so the agent also needs those rules for each carrier.

Disputes are won or lost on shipper-side evidence. A certified scale reading at the dock, a packing list weight and a photo of the pallet on the scale carry weight with carrier dispute teams; a declared weight with nothing behind it rarely does.

A common mistake is disputing everything. An agent that recommends accepting reweighs where the shipper has no scale record saves effort for the disputes that can be won.

Playbook 3: reclasses#

A reclass playbook has the agent compare the freight class and NMFC item on the bill of lading with the product master, the measured dimensions and the dock photos, then recommend accepting or disputing the carrier's inspection. Because class depends on density, commodity description and packaging, a reclass often reveals that the product master is out of date.

A useful agent does two things: it handles the dispute on this shipment and flags the item so the product master is corrected before the next one ships. Without the second step, the same reclass comes back on the next load. NMFC classifications are also revised from time to time, so a class that was right when an item was set up may need checking against the current classification rather than assumed.

Reclass evidence also includes the commodity description on the bill of lading. A vague description invites inspection, while one that matches the product master and the NMFC item leaves the carrier less room to rebill.

The three playbooks side by side#

Side by side, the three playbooks share one structure: a trigger, an evidence set and an outcome worth recording. The outcome column is the one most teams skip, and it is the one that lets anyone, a new analyst or a model, learn from past exceptions.

What makes LTL exception history useful?#

LTL exception history is useful when each case links the shipment, the evidence, the action and the result. A note that says 'disputed reclass' is a start; a case that shows the billed class, the product master entry, the photos, the dispute and the credit decision is a record someone can learn from.

Illustrative: a managed transportation provider's LTL desk#

Illustrative: a fictional managed transportation provider runs the LTL desk for several shippers, including a maker of packaged furniture. Reclasses on that shipper's freight keep recurring, and each dispute takes rounds of email to collect dimensions and photos.

The COO pulls the closed exceptions for the account and finds the pattern: several products were repackaged in larger cartons, but the product master still carried the old dimensions and class. The team corrects the master, requires dock photos for those items and pilots an agent that assembles the evidence bundle for every new reclass before an analyst decides.

The outcome: fewer repeat reclasses on that account and dispute files that are complete on the first send. The cleaned history also becomes a far better record of how LTL exceptions are actually resolved.

Exception history as a licensable record#

LTL exception history with outcomes is a record type AI developers building logistics agents look for, because it shows how real problems were diagnosed and resolved. A company that keeps it well can use it twice: to run its own agents and, if it chooses, to license it while keeping ownership.

SourceX assesses that history through the SourceX five-step transaction of Supply, Rights, Preparation, Approval and Delivery. Shipper names, consignee addresses and contact details are removed in Preparation, carrier contract and client terms are checked in the Rights step, and each approved package is documented in a SourceX Evidence Packet.