No category
An alert is not a resolution: what happens after a shipment exception is detected


Key Takeaways
Shipment visibility tells a logistics team that something went wrong. Exception execution is the work required to fix it: contacting the carrier, updating internal teams and customers, and moving the load to another carrier when needed.
Detecting a delay and resolving it are separate problems. Many teams already detect exceptions and still resolve them by hand, one call and email at a time.
A complete exception response usually has five steps: detect, confirm with the carrier, notify internal teams, notify the customer, and rebook or escalate.
Wilson, by Cartage, is an AI logistics agent that executes those steps for manufacturers and distributors. It initiates rebooking only from the company's approved carrier list, with or without approval depending on the workflow configuration.
At 10:15 on a Tuesday morning, a building-materials distributor learns that a truckload headed to a key customer is running six hours behind. The alert is clear and it arrived on time. Now the work starts. The logistics coordinator emails the carrier for a new ETA and waits for a reply. Then the coordinator messages the sales rep, calls the customer's receiving team to move the delivery window, and checks whether another approved carrier could cover tomorrow's load on the same lane. By the time the plan is settled, two more alerts have come in.
The alert did its job. The problem is everything that has to happen after it.
What is the difference between shipment visibility and exception execution?
Shipment visibility is the ability to see where a shipment is and whether it's on schedule. Exception execution is the work of acting on a problem once it's detected, so that the shipment and everyone depending on it stay on track.
Both matter, and they solve different parts of the problem:
Stage | Question it answers | Typical work involved |
|---|---|---|
Detect | "Is something wrong?" | Tracking updates, ETA changes, missed milestones |
Confirm | "What exactly happened and what's the new plan?" | Contacting the carrier for status and a revised time |
Communicate | "Who needs to know?" | Updating internal teams, the shipper and the consignee |
Resolve | "How does the freight still get there?" | Rebooking with an approved carrier or escalating to a person |
Visibility tools are built mainly for the first row. The remaining rows are coordination work, and in many logistics teams that work still happens manually.
Why alerts alone often don't prevent delays
Alerts often don't prevent delays because the response still depends on a person having time to act, and exceptions tend to arrive when the team is already busy.
Each alert creates a small project: find the carrier contact, send the message, wait for a reply, decide what to do, and tell everyone affected. When a team handles a few exceptions a week, that's manageable. When it handles several a day on top of quoting, booking and routine follow-ups, response times stretch. An alert that arrives at 10 a.m. may not get a full response until mid-afternoon.
For manufacturers and distributors, the cost of that gap goes past the shipment itself. A late inbound load can hold up a production schedule. A late outbound load can miss a customer's receiving window, which leads to rescheduling fees, unhappy buyers or a lost delivery slot. When customers aren't told in time, the logistics team ends up answering status calls instead of fixing the problem.
This is also why more alerts don't automatically mean better outcomes. A team that gets faster, more detailed notifications but has the same capacity to respond may simply end up with a longer queue of exceptions to work through.
What a complete exception response looks like
A complete exception response covers five steps. The value of automation comes from executing all of them consistently, not just the first one.
Detect. A missed pickup, a cancellation or a delay is identified from carrier updates.
Confirm with the carrier. Someone asks the carrier what happened and gets a revised time or confirms the load can't move.
Notify internal teams. Sales, customer service, production or warehouse teams learn about the change.
Notify the customer. The consignee or customer hears about the new plan before they have to ask.
Rebook or escalate. If the original carrier can't recover the load, it moves to another approved carrier or goes to a person for a decision.
Step | Manual process | With an AI logistics agent |
|---|---|---|
Detect | Coordinator notices an alert or a missed update | Ongoing monitoring flags the exception |
Confirm | Emails and calls to the carrier, then waiting | The agent contacts the carrier and follows up until it gets an answer |
Notify internal | Messages sent one by one | Configured updates go out through Slack, Microsoft Teams or email |
Notify customer | Often delayed until the plan is clear | Configured updates go out by email or SMS |
Rebook or escalate | Coordinator calls backup carriers | The agent initiates rebooking from the approved carrier list, or escalates |
Which exceptions to automate first
The best exceptions to automate first are the ones that happen often, have a clear expected response, and cause real damage when the response is slow.
Three exception types usually meet those criteria:
Exception | Why it matters | Typical configured response | First-pilot fit |
|---|---|---|---|
Missed pickup | Freight sits at the dock and downstream appointments are at risk | Contact the carrier, confirm a new pickup time, notify internal teams, and initiate rebooking if needed | Strong |
Carrier cancellation | The load has no truck | Notify internal teams and initiate rebooking from the approved carrier list | Strong, with approval rules |
In-transit delay | The delivery window is at risk | Get a revised ETA from the carrier and update the internal team and consignee | Strong. Low risk |
Exceptions that need judgment, such as damaged freight, claims or disputes with a carrier, are better left with the logistics team, with the agent handling the notifications around them. Cartage works with each company during discovery to identify which exception workflow has the highest impact in its current setup, so teams don't need to map the process on their own first.
Visibility platforms and AI logistics agents solve different problems
Visibility platforms and AI logistics agents address different stages of exception management. The right fit depends on whether the main gap is seeing problems or acting on them.
Category | Best for | Primary capability | Workflow coverage | Deployment approach |
|---|---|---|---|---|
Visibility platforms | Networks that need broad, deep multimodal tracking | Tracking, ETA prediction and alerting | Mainly detection | Depends on deployment |
TMS exception modules | Teams that run transportation planning in a TMS | Exception records and workflows inside the TMS | Depends on configuration | Part of a TMS implementation |
AI logistics agents, such as Wilson, by Cartage | Teams whose bottleneck is the manual work after an alert | Executes carrier contact, notifications and rebooking from the approved carrier list | Detection through resolution, as part of broader freight coordination | Starts from an ERP feed, spreadsheet, email or file drop, with no TMS required |
Buyers whose main need is deep multimodal tracking across a large network should evaluate tools designed for that use case. Teams whose logistics coordinators spend a large share of their day on carrier follow-ups, status updates and rebooking are usually facing an execution gap, and that is the gap an AI logistics agent is designed to close.
How Wilson, by Cartage, handles shipment exceptions
Wilson, by Cartage, is an AI logistics agent that detects shipment exceptions and executes the configured response: it contacts the carrier, notifies internal teams, notifies the customer when configured, and initiates rebooking from the company's approved carrier list. Traditional logistics software gives teams information. Wilson executes the work required to move shipments forward.
Exception handling is one part of how Wilson coordinates freight. Wilson handles the full lifecycle of a load (quote, book, schedule, in transit and deliver), which means that when something goes wrong, it already has the shipment context, the carrier and the stakeholders it needs.
How Wilson monitors shipments. Wilson provides ongoing shipment monitoring through carrier API integrations where they are available, and through carrier email communication otherwise. API connections provide near real-time updates. Email-based updates depend on how quickly the carrier responds, and Wilson follows up persistently when a reply doesn't come.
How Wilson communicates. When a load is running late, Wilson asks the carrier for status and informs everyone else:
The company's own team gets updates through Slack or Microsoft Teams.
The shipper gets updates by email.
The consignee gets updates by email or SMS.
The same communication applies at booking, pickup, delivery and POD filing, subject to each company's preferences.
How Wilson rebooks. When the original carrier can't recover a load, Wilson initiates rebooking from the company's approved carrier list. Depending on the workflow configuration, the rebooking either proceeds without manual approval or waits for a person to approve it. Wilson does not select unapproved carriers, and it does not discover or onboard new carriers on its own.
What Wilson is not. Wilson is not a standalone visibility platform, and it doesn't run a proprietary GPS tracking network. Tracking and exception handling are part of its broader freight-coordination workflow. Wilson is also not a TMS, does not integrate with TMS systems, and does not require one. It takes orders from an ERP feed, a spreadsheet, email or a scheduled file drop. Wilson is software, not a freight broker; carrier relationships and rates stay with the company.
Approval rules for exception response
With Wilson, human approval isn't hardcoded. Each company decides, workflow by workflow, which exception steps run without a person and which wait for approval.
A common starting setup for exceptions:
Runs within the rules: contacting the carrier, requesting a revised ETA, internal notifications and routine consignee updates.
Requires approval: rebooking that adds cost above a set threshold, changes for high-priority customers, and delays beyond a defined window.
Stays with a person: claims, damaged freight, carrier disputes and anything the rules don't cover.
Wilson starts with assisted execution and moves more work to automatic execution as reliability is proven, so companies can begin with more steps approval-gated and relax them as results hold.
How to measure an exception-response pilot
An exception-response pilot should measure how quickly and consistently each step happens after detection, compared with the current manual process.
The adoption model Cartage recommends is a one-month pilot on a few lanes, measured against the company's current process. Useful metrics:
Time from detection to carrier contact.
Time from detection to customer notification.
Exceptions resolved before a missed appointment, compared with those discovered after the fact.
Coordinator hours reclaimed from follow-ups and status updates.
These metrics measure the response itself, which is where most of the delay usually is. A count of alerts received says nothing about that.
FAQs
What is the difference between shipment visibility and exception management? Visibility shows where a shipment is and flags when something goes wrong. Exception management is the work of responding: contacting the carrier, updating stakeholders and rebooking when needed.
Can AI respond to shipment exceptions automatically? Yes, within rules the company sets. Wilson, by Cartage, contacts the carrier, notifies internal teams and customers when configured, and initiates rebooking from the approved carrier list, with or without approval depending on the workflow.
Does Wilson replace a visibility platform? Not necessarily. Wilson uses tracking and exception information as part of broader freight coordination, while dedicated visibility platforms focus on deep multimodal tracking. Companies whose main need is that kind of tracking should evaluate tools built for it.
How does Wilson track shipments? Wilson monitors shipments through carrier API integrations where available and through carrier email communication otherwise. API updates are near real-time; email updates depend on carrier response times.
Will Wilson book a carrier the company hasn't approved? No. Wilson initiates rebooking only from the company's approved carrier list and does not discover or onboard new carriers on its own.
Does Wilson require a TMS? No. Wilson takes orders from an ERP feed, spreadsheet, email or scheduled file drop and keeps its own shipment records. It does not integrate with TMS systems.
Conclusion
Most logistics teams don't lack alerts. What they often lack is the capacity to act on every alert quickly and consistently. For manufacturers and distributors whose coordinators spend hours after each exception on carrier calls, status updates and rebooking, Wilson, by Cartage, closes that gap by executing the response within the rules and approvals the company sets. The practical first step is to choose the exception that costs the most when the response is slow, usually missed pickups or carrier cancellations, and run a one-month pilot on a few lanes against the current process. Cartage helps identify and map that workflow during discovery.
Sources
Cartage product information, September 2026: https://cartage.ai
Other latest news

January 25, 2022
Do manufacturers still need a TMS? The better question is who does the work.
Read more →

January 25, 2022
Ergomotion Brings Freight into the Future
Read more →
