Customer shipment updates should start with a carrier-confirmed answer

Key Takeaways

A customer update is a promise, so send it when the carrier has confirmed the status or ETA, not when a scan, ping or predicted ETA first changes.
Write the rule per event: booked, picked up, running late, delivered and POD filed each need different evidence.
A provisional notice is the exception: a late load, an appointment at risk and a carrier who hasn't answered yet.
Seeing that a status changed is visibility. Getting the carrier's answer and telling the right people is execution work that needs an owner.
Wilson, by Cartage, gets the confirmed status from the carrier and sends each update to the people the company configures.

Why should a customer update wait for the carrier's answer?

Because the customer acts on what you send. If the update came from a signal the carrier never confirmed, the customer re-plans a dock crew, a production run or a promise to their own buyer around something that may not be true.

Raw tracking signals describe symptoms. An ELD ping shows a truck stopped for an hour and a half, 40 miles short of the consignee: a required rest break, a flat tire or traffic. A missed terminal scan on an LTL load can mean the freight was left behind, or that nobody scanned it. A predicted ETA that slides past the appointment is a calculation, not a statement from the people moving the freight. Each says something might have changed. None says what the carrier will do next.

Forward those signals and some updates will need corrections; customers then start calling to verify every message.

The opposite failure is silence while the team waits for certainty. A good rule settles both in advance: what counts as confirmed for each event, and how long the customer can go without hearing anything. When feeds and carrier emails contradict each other, settle which wins first; see the carrier email and tracking feed disagree.

How do you write an update rule for each shipment event?

Write one short rule per customer-facing event, with the same parts every time, so nobody improvises when a signal changes on a busy afternoon.

List the events customers receive. Most manufacturers and distributors use five: booked, picked up, running late, delivered and POD filed.
Name the signal that starts the work. A tender sent, a pickup window passing, a stalled ping, an arrival at the consignee, a note that paperwork is available.
Define the confirmation standard. The carrier's own status for that load, a dispatcher's reply, a driver's call or a signed document.
Set a holding window. How long to keep trying to confirm before a provisional notice goes out or a person steps in. As an illustration, half an hour for a late load with a same-day appointment, two hours for one due next week. The number comes from each customer's ability to re-plan.
Name the audience and channel. Internal team in Slack or Microsoft Teams; shipper, consignee or customer service contact by email or SMS.
Decide whether customer messages need approval at first, while the team reviews early updates.

What counts as a carrier-confirmed answer in practice?

Each event is a different claim about the freight, so each needs different evidence.

Booked: the carrier accepted the tender and confirmed a pickup window. A selected rate isn't a booking.
Picked up: the carrier's status, a dispatcher or the driver confirms the freight is on the truck. A truck leaving the yard on a location feed doesn't prove it; refused pickups look like departures too.
Running late: the carrier gives a new ETA and a reason. A predicted ETA past the appointment is the trigger to ask, not the message.
Delivered: the carrier confirms delivery, and the consignee where available. An arrival at the consignee's location may mean the driver is waiting at the gate.
POD filed: the signed document is in hand, legible and matched to the shipment. A shortage or damage notation goes to the internal team before the customer gets a routine message.

A status the carrier publishes for the load, through its API or its website by PRO number, is the carrier speaking and can be enough for routine events. A location ping or an estimate should start a question to the carrier, by email or by phone where configured, not a message to the customer.

When is a provisional notice better than waiting?

Send a provisional notice only when waiting would cost the customer more than an incomplete message: a late load, an appointment the customer must re-plan around, and a carrier who hasn't answered inside the holding window.

Say what's confirmed and what isn't. "Possible delay on PO 7731; we're confirming a new ETA with the carrier; next update by 2 p.m." is useful. "Delayed due to weather" without a carrier statement is a guess.
Never send a provisional delivered or POD message. A wrong delivered status becomes a receiving dispute.
Tell the internal team first, so customer service isn't surprised by a call.
Follow up with the confirmed answer, even if it's "the original ETA holds."

When you evaluate software against this policy, ask it to show the raw signal and the carrier confirmation as separate, timestamped entries on the shipment. If they collapse into one status, you can't tell which updates went out on evidence. For the evidence behind a revised ETA, see confirm the carrier before sending the customer a new ETA; for who hears each status first, see who needs to know first.

Update-readiness rule by event type

Use this as a starting rule and adjust recipients per customer.

Event	Signal that starts the work	Ready to send when	Provisional notice?	Default recipients
Booked	Rate selected or tender sent	Carrier accepted the tender and confirmed a pickup window	No	Internal team, shipper
Picked up	Pickup window passes or truck leaves the yard	Carrier status, dispatcher or driver confirms the freight is loaded	Internal team only, if the window passed with no answer	Internal team, shipper, consignee
Running late	Stalled ping, missed scan or predicted ETA past the appointment	Carrier gives a new ETA and a reason	Yes, if the appointment is at risk and the holding window has expired	Internal team first, then shipper and consignee as configured
Delivered	Arrival at the consignee's location or a tracking page change	Carrier confirms delivery; consignee confirms where available	No	Internal team, shipper, consignee
POD filed	Carrier says paperwork is available	Signed POD received, legible and matched to the shipment	No; exceptions noted on the POD go to the team first	Internal team, shipper, consignee

Before adopting it, pull three examples from last month: a load where the customer called before you told them (the holding window was too long), a correction you had to send (a signal went out unconfirmed), and one customer whose recipients differ from the default.

How does Wilson, by Cartage apply a carrier-confirmed update rule?

Wilson is an AI logistics agent that replaces the TMS for freight execution; it is not a standalone visibility platform. It tracks each load as part of moving it.

It uses the best source per load: the carrier's API, GPS or ELD data where available, or the carrier's website by PRO number. When those don't answer the question, it emails the carrier or calls where configured. When a load runs late, it gets the new ETA and reason from the carrier, then notifies the people the company has set up.

Each company chooses who receives what. The internal team can get booked, picked up, running late, delivered and POD filed updates in Slack or Microsoft Teams; the shipper can get the same five by email; the consignee can get all but booked, by email or SMS. Wilson starts with assisted execution, so customer notifications can require approval until the team trusts the rule.

When the carrier can't confirm, or the delay needs a decision such as rebooking from the approved carrier list above a cost threshold, Wilson escalates to the team instead of guessing. Messages, confirmations and changes are recorded in shipment history.

Bring the update rules you give customers today, plus one load where a tracking signal ran ahead of the carrier, and see Wilson turn that signal into a confirmed customer update.