Freight exception software should resolve the issue, not just send an alert

Key Takeaways

Judge freight exception software by the state it leaves the shipment in, not by how fast it raises the alert.
Write your own definition of resolved for each exception type before any vendor shows you theirs.
An exception has only three honest end states: closed with evidence, handed to a named person with a specific decision, or still open. Acknowledged, viewed and assigned are not end states.
Closure needs proof on the shipment: the confirmed fact, its source, who was told and any approval.
Wilson, by Cartage, is an AI logistics agent that contacts the carrier, gets the new ETA and reason, notifies configured people, initiates rebooking from approved carriers under the company's rules and escalates what falls outside them, with messages, confirmations and changes recorded in shipment history.

What should resolved mean when you buy freight exception software?

An exception is resolved when the shipment has a confirmed next state and the record shows how it got there. Anything less is a notification with extra steps.

Detection is visibility: knowing a pickup window passed or an ETA slipped. Resolution is execution: doing the follow-up until the load has a plan someone can rely on. Many products mark an exception as handled when a user clicks acknowledge or a ticket is assigned. That status describes the software's queue, not the freight.

So the buyer's first job is definitional: write down what resolved means for each exception you see often. For a late load, a carrier-confirmed ETA with a reason, delivered to the customer if your rules require it. For a missed pickup, a confirmed new time from the original carrier or an accepted tender from an approved replacement. Software that cannot reach that state or hand it cleanly to a person is an alerting tool.

The order of operations is covered in what happens after an exception alert. The narrower question is when a vendor may call the exception done.

The resolution steps and where each one is allowed to end

Resolution runs through five steps, and each one either produces a confirmed fact or a reason to move to the next.

Contact the carrier. The step ends when the carrier has answered with something usable, or when the configured follow-up has been exhausted. A sent email is an attempt, not an answer.
Get the new ETA and the reason. The step ends with a time and a cause from the carrier, tied to the load. A predicted ETA from a stale location ping does not close it, because nobody at the carrier has committed to it.
Notify the configured people. The step ends when the team, and the customer or consignee where configured, have received the confirmed facts, not a raw alert. Notice sent before step 2 usually has to be sent again.
Rebook from approved carriers under the rules. Only when the original carrier cannot recover. The step ends when an approved carrier accepts and the original carrier is released, so two trucks are not heading to one dock.
Escalate. The step ends when a named person receives the decision with options gathered: which approved carriers declined, the alternatives and the deadline.

Not every exception uses all five; a late in-transit load rarely needs rebooking. What matters is that the software stops at a defined point instead of drifting.

What evidence of closure should exist on the shipment

If closure cannot be reconstructed from the shipment record, it was resolved by memory. Ask every vendor to open a closed exception and show these fields.

The confirmed fact and its source. The new pickup time, ETA or acceptance, plus where it came from: a carrier API event, GPS or ELD data where available, the carrier website by PRO number, or an email or call with the carrier.
Timestamps for each step. Detection, first carrier contact, the answer and the notices. Gaps show where work waited.
Who was notified, through which channel. The team in Slack, Microsoft Teams or email; the customer by email or SMS where configured.
The carrier commitment. For a rebooking, the tender, the acceptance and the rate confirmation from the replacement carrier, and the message releasing the original carrier.
The approval, if one was needed. Who approved, what they approved and what the rule was.
What remains open. A delivery appointment still to move, or a likely accessorial, should be visible.

A visibility tool records that the exception happened. An execution tool records what was done about it and what the shipment looks like now.

How should a buyer score a vendor's idea of resolved?

Score the end state of each exception, not the number of features that touched it. Give every test exception one of three grades.

Closed: the confirmed next state exists, the right people know it, and the record proves both.
Handed off correctly: the case fell outside the configured rules, and a named person received a specific decision with the context attached. This is a pass.
Open: anything else, including acknowledged alerts, assigned tickets and exceptions that a coordinator finished by phone outside the tool.

Then apply rules that catch weak definitions.

A reason is required. Without a cause, nobody can judge whether the next ETA will hold.
Release counts. A rebooking that leaves the original carrier still dispatched is not closed.
Reopening must be automatic. If the confirmed ETA slips again, the exception reopens rather than staying closed on old information.
Approvals must hold. A rebooking above your limit without approval fails, even if the load moved.
Silence is a state. When the carrier never answers, the right end state is an escalation, not an exception sitting quietly at contacted.

To add the clock, see measure recovery, not just delay detection.

Resolution criteria by exception type

Use this table as the buyer's definition sheet. Add your approval limits and customer rules, then grade each test exception against its row.

Exception type	Resolved means	Evidence of closure	Still open if
Missed pickup, carrier can recover	Original carrier commits to a new pickup time that fits the delivery commitment	Carrier reply with the time, team notice, customer notice where configured	The carrier said the truck is coming but gave no time
Missed pickup, carrier cannot recover	An approved replacement accepts and the original carrier is released	Tender, acceptance, rate confirmation, release message	Only a list of carriers to call was produced
Carrier cancellation	Approved replacement booked within the rules, or approval requested with options	Cancellation message, replacement acceptance or approval request	The cancellation was logged and nothing else happened
Late in-transit load	Carrier-confirmed ETA and reason delivered to the configured people	ETA with source and time, the reason, notice records	The ETA came from a stale signal with no carrier confirmation
Carrier not responding	Answer obtained through follow-up, or escalation to a named person	Each attempt by channel and time, the handoff	Attempts stopped without a handoff

An illustrative way to read it: if a vendor works through five test exceptions and three end as closed, one as handed off correctly and one as open, the open one is where your coordinators will still spend their afternoons.

How Wilson, by Cartage, works an exception to closure

Wilson treats an exception as work to finish, not a status to display. It replaces the TMS for freight execution and connects to the company's ERP.

Wilson tracks each load through the best source available and, when an exception appears, contacts the carrier by email, API, EDI where supported, or phone where calls are configured. For a late load, it gets the new ETA and the reason, then notifies the team in Slack or Microsoft Teams and the customer by email or SMS where configured. For a missed pickup or cancellation, it initiates rebooking from the company's approved carriers, automatically within the rules or with approval, depending on configuration. If no approved carrier accepts, or the decision is outside the approval limits, Wilson escalates to the team with the attempts and options attached.

Messages, confirmations and changes are recorded in shipment history, so a buyer can grade each exception against the table above. Wilson starts with assisted execution, and its scope can expand step by step as the team gains confidence. The broader model is explained in what an AI logistics agent is.

Bring one exception your team closed by hand last month, with the emails that closed it, and see Wilson take the same exception to a closed state in a demo.