Shipment tracking and exception resolution solve different jobs

Key Takeaways

Shipment tracking and exception resolution are two jobs with different inputs, outputs, owners and success measures; scope and buy them separately even if one product does both.
Tracking turns carrier signals into a trusted status. Resolution turns a status that breaks the plan into a closed outcome.
The handoff between them is the part most scopes leave undefined: what condition triggers it, what information travels with it, and who accepts it.
Measure tracking by freshness and coverage, and resolution by time to a closed outcome; mixing the two hides which job is failing.
Wilson, by Cartage, runs both jobs on the loads it executes, with the handoff governed by the company's configured rules and approval limits.

Why should tracking and resolution be scoped as two jobs?

Because they fail for different reasons and are fixed by different things. Tracking fails when the status is missing, stale or wrong. Resolution fails when a correct status reaches nobody who can act, or reaches someone who has no authority to fix it.

Buying teams often write one requirement, "know where shipments are and handle problems," and score tools against it. A tracking-strong product then wins the review while the team still chases carriers by phone, or a workflow-strong product wins a scripted exception and then runs on stale statuses.

Splitting the work forces three useful decisions before any demo. First, what counts as a good status, and from which sources. Second, what counts as a resolved exception, and who signs off. Third, where one job ends and the other begins. That third decision, the handoff, is where most freight teams lose hours, because nobody owns the gap between "we know" and "someone is on it."

What each job takes in, produces and owns

The tracking job

Inputs: load identifiers (PRO, BOL, reference numbers), the carrier, the appointment windows, and whatever source answers for that load: carrier API, GPS/ELD where available, the carrier website by PRO number, or an email or call to the carrier.
Output: a status with a timestamp and a named source, plus an ETA that someone can rely on.
Owner: whoever maintains the status record. Its decision rights are narrow: ask, record, publish.
Done when: the load is delivered and the POD is on file.

The exception resolution job

Inputs: the status that broke the plan, the order or commitment it affects, the approved carrier list, the company's rules (cost limits, who must be told, which actions need approval) and the deadline that matters, such as a line start or a customer window.
Output: a closed outcome: a confirmed new pickup, a rebooked load with an approved carrier, an accepted late delivery the customer has been told about, or an escalation with a named decision-maker.
Owner: someone with authority to change the plan within limits, and a named person above those limits.
Done when: the outcome is confirmed and recorded, not when the alert is acknowledged.

Tracking is a reporting job with few decisions; resolution is a decision job that depends on good reporting.

How to design the handoff point

The handoff is a contract between the two jobs. Define it in three parts.

The trigger. Not every status change is an exception. Write the conditions that move a load from tracking to resolution: a pickup not confirmed by a set time after the window opens, an ETA that now lands after the delivery appointment, a carrier cancellation, a status that has not refreshed for longer than the lane tolerates. Everything else stays in tracking.

The handoff packet. Resolution should never re-ask what tracking knows. The packet carries the load and order references, the current status with its timestamp and source, what the plan required, the gap between the two, the carrier contact, and which commitment is now at risk. If the receiving owner has to open three systems to rebuild this, the handoff is broken.

The acceptance. Someone, or something, must take ownership explicitly. A handoff that lands in a shared channel without an owner is still an alert. Write who accepts each trigger type and what happens if nobody accepts within the time the rule allows.

The handoff also runs backward. When resolution produces a new plan, such as a new carrier or a new appointment, tracking needs the new identifiers so it can follow the replacement load. Without this return path, teams end up tracking a cancelled shipment. Response times per exception type belong in an exception-response SLA that names the next owner; the handoff design comes first, because no SLA holds when the packet arrives incomplete.

How to measure each job and decide what to buy

Keep separate measures so a weak job cannot hide behind a strong one.

Tracking measures: the share of active loads with a status refreshed within the tolerance you set per lane; how many loads have no automated source and depend on email or calls; how often the ETA moved after the customer was told.

Resolution measures: time from trigger to accepted ownership; time from acceptance to closed outcome; share of exceptions closed within the configured rules versus escalated; repeat contacts to the same carrier for the same load.

Handoff measures: triggers that fired with an incomplete packet, and exceptions found by a customer or the plant before the trigger fired. The second one is the clearest sign the trigger conditions are wrong.

Decision rules for scoping a purchase:

If tracking measures are weak and resolution measures are fine once someone knows, buy better tracking.
If tracking is adequate but time from trigger to closed outcome is long or inconsistent, buy resolution, and test it with your rules and approved carriers.
If many loads depend on email or calls for status, treat tracking and resolution as one workload for those loads, because the person asking for status is usually the person who then fixes the problem.
Whatever you buy, require the handoff packet and the return path in writing.

A two-column job definition with the handoff in the middle

Use this as the scoping sheet. Fill in the bracketed parts for your own operation.

Element	Tracking job	Exception resolution job
Question it answers	Where is the load, and when will it arrive?	What do we do now that the plan broke?
Starts with	A booked load and its identifiers	A trigger from tracking, plus the affected order
Sources or tools	Carrier API, GPS/ELD, PRO lookup, email or calls	Approved carriers, approval rules, stakeholder list
Output	Timestamped status and ETA with source	Confirmed outcome or named escalation
Owner	[Status owner]	[Exception owner] up to [limit]; [manager] above it
Success measure	Freshness and coverage per lane	Time from trigger to closed outcome
Failure looks like	Stale or missing status	Alert acknowledged, nothing changed
Handoff	Sends: references, status, timestamp, source, plan gap, commitment at risk	Accepts within [time]; returns new identifiers to tracking

Test the sheet on one recent exception, such as a missed pickup. If any cell is blank or the answer is "it depends who's working," that is the part to fix or buy first.

How Wilson, by Cartage runs both jobs and the handoff

Wilson, by Cartage, is an AI logistics agent that replaces the TMS for freight execution and connects to the company's ERP; it is not a freight broker or a standalone visibility platform. On the loads it runs, it does the tracking job from the best source per load, falling back to email or calls when automated sources don't answer.

The handoff is set by the company's configuration rather than left to whoever sees an alert. When a load is running late, Wilson gets a new ETA and the reason, notifies the configured stakeholders through Slack, Microsoft Teams, email or SMS, and recovers or escalates under the company's rules. When a pickup is missed or a carrier cancels, Wilson contacts the carrier, notifies the team and the customer if configured, and starts rebooking from the company's approved carriers. If no approved carrier accepts, or the action exceeds an approval limit, it escalates to a person with what has already been tried. The new booking goes back into tracking, and messages, confirmations and changes are recorded in shipment history.

Wilson starts with assisted execution, the company sets the approval boundaries, and the scope can expand as the team gains confidence. For the broader model, see what an AI logistics agent actually does.

Bring your filled-in job definition and one missed pickup from last week, and watch Wilson carry it across the handoff from status to closed outcome.