The situation
The client operates a third-party logistics network coordinating freight across four regional carriers, moving roughly 14,000 shipments a week for its retail and manufacturing clients. Its dispatch team of nine people spent, by their own time-tracking, close to 60% of their working hours not on route planning or client communication, the parts of the job that actually required judgment, but on chasing down shipment exceptions: address corrections, delivery delay rebooking, damaged-goods claims intake, and carrier-side documentation mismatches.
Each of the four carriers had its own exception-notification format, its own rebooking rules, and its own claims process, and a meaningful share of dispatcher time was spent simply translating between them: checking one carrier's portal for a delay notice, then manually re-entering the same shipment details into a different carrier's rebooking form because the two systems didn't talk to each other.
Why off-the-shelf didn't fit
Multi-carrier transportation management systems (TMS platforms) exist specifically to unify carrier data, and the client already ran one. The problem wasn't visibility, it was action. Their existing TMS could show a dispatcher that carrier B had flagged a delivery exception; it couldn't resolve that exception, because doing so required carrier-specific logic (carrier B allows an address correction via API up to two hours before the delivery window; carrier D requires a phone call for any address change at all) that a generic TMS integration wasn't built to encode. Every "AI logistics" vendor the client evaluated assumed a level of carrier API standardization that, in this client's specific carrier mix, simply didn't exist: two of the four carriers had meaningfully incomplete or inconsistently documented APIs, and one required an EDI-based integration pattern that most modern automation vendors don't support at all.
Scoping the real workflow
We spent the first week of the engagement carrier by carrier, working with the client's carrier-relations manager (whose job function, tellingly, existed specifically to manage these inconsistencies) to document exactly what each carrier's API could and couldn't do automatically, where the gaps required a phone call or a portal action, and which exception types were high-volume enough to justify automating versus rare enough to leave with a human. This produced what became the actual engineering backbone of the project: a per-carrier capability matrix mapping each exception type to an automatable action, a portal-automation workaround, or an explicit "route to dispatcher" decision.
We also asked dispatchers to flag, over a two-week sample period before the scope call concluded, every exception they resolved that they considered genuinely judgment-based rather than mechanical, such as a client-specific delivery preference that wasn't written down anywhere, or a carrier relationship consideration that affected which rebooking option to choose. That list became the explicit boundary of what the agent would not attempt to resolve on its own.
What we built
The agent monitors exception feeds from all four carriers continuously: API webhooks for the two carriers with modern integrations, scheduled polling of carrier B's less complete API, and a purpose-built portal-automation layer for the carrier whose only practical integration surface was its own web portal, built narrowly for this specific portal's structure rather than as a general-purpose browser agent. For each incoming exception, it checks the exception type against the capability matrix built during scoping: if it's a known, automatable case (address correction from a source the agent can verify, delay rebooking within the carrier's standard rules, initiating a damaged-goods claim with photos and shipment data already attached), it takes the action directly and logs it. If it falls outside that matrix, including every case the dispatchers themselves had flagged as judgment-based during scoping, it's routed to a dispatcher with the relevant shipment and carrier context already assembled, rather than requiring the dispatcher to go pull that context themselves.
Where it got hard
The carrier requiring portal automation was the hardest engineering problem in the project, and it's worth being specific about why: that carrier's web portal had no public API, its session-handling was aggressive about logging out automated-looking traffic, and its form structure changed without notice at least once during our build period, breaking our first working version three days before we'd planned to demo it. We rebuilt that integration with more defensive error-handling and an internal monitoring check that alerts our team directly if the portal's structure changes again, rather than silently failing, a safeguard that has since caught two further unannounced portal changes without any shipment falling through unresolved.
The other real difficulty was trust calibration with the dispatch team, which is a people problem more than a technical one. Dispatchers were, reasonably, skeptical of a system automatically taking actions, such as initiating a damaged-goods claim, that they'd previously handled personally and felt accountable for. We addressed this by making every automated action fully visible and reversible within a short window in the existing TMS interface dispatchers already used daily, rather than hiding automated actions in a separate system, and by running two weeks of the agent operating in a "propose, don't execute" mode where it drafted the action but a dispatcher had to approve it with one click before it went live. That built enough trust that the team asked, on their own, to flip to full automation two days ahead of the schedule we'd proposed.
Rollout & results
The agent now resolves 78% of incoming shipment exceptions without dispatcher involvement, with the remaining 22% routed to a dispatcher with full context pre-assembled rather than requiring manual investigation. Dispatch team capacity freed up by the automation has been redirected, per the client's own account, toward proactive client communication on at-risk shipments, a shift from purely reactive exception-handling to something closer to genuine account management, which the client's leadership has said mattered more to their retail clients than the raw efficiency gain.
"The part I didn't expect was that our dispatchers ended up liking their jobs more, not less. The tedious 60% of the role disappeared and what was left was the part they actually wanted to be doing." Director of Engineering, client engagement
What we'd do differently
We'd build the portal-change monitoring safeguard for the fourth carrier from day one rather than adding it reactively after the first break. Any engagement that depends on browser/portal automation against a system without a real API should assume the target will change without notice, and we now scope monitoring and graceful-failure handling as a standard line item for that specific integration pattern rather than an afterthought.