No category
Confirm the Carrier Before Sending the Customer a New ETA
Key Takeaways
A revised ETA should reach a customer only after it clears an evidence bar the company sets in advance, usually a carrier confirmation with a reason.
Internal teams can act on weaker evidence than customers should hear. A risk flag is enough for logistics, not for the consignee.
An event, evidence and recipient matrix sets, for each shipment event, what proof is required and who gets which update.
Wilson, by Cartage, confirms the ETA with the carrier, then updates the contacts configured on each shipment. Customer messages can be set to need approval.
When the carrier can't confirm, the customer gets confirmed facts and a time for the next update, not a guessed ETA.
When is a new ETA verified enough to send to the customer?
A new ETA is ready for the customer when the carrier has confirmed it, the reason is known, and no fresher source contradicts it. Anything less is an internal signal: useful to the team, but not yet a promise.
Customers act on the ETAs they receive. A receiving manager moves a dock crew, a plant reschedules a line, a branch tells its own buyers when stock will arrive. A wrong revised ETA can cost them more than the original delay, and a second correction a few hours later costs trust that is hard to win back.
It helps to name three levels of evidence:
Signal. A predicted delay, a stale feed or a missed scan. Something may be wrong.
Corroborated. Two independent sources agree, such as a GPS position that fits a carrier website status.
Confirmed. The carrier's dispatcher or driver states the new ETA and the reason, and the confirmation is recorded on the shipment.
Most companies send customers only confirmed ETAs and keep signals inside the team. The guide to updating a customer about a delayed delivery covers what the message should say. The question here comes earlier: has the ETA earned the right to be sent, and to whom?
The event, evidence and recipient matrix
For every shipment event, the matrix answers three questions: what happened, what proof is needed before each audience hears about it, and who exactly receives it.
Event. Booked, picked up, at risk, running late, ETA changed again, delivered, POD filed. "At risk" and "running late" are different events. The first rests on a signal, the second on a confirmation.
Evidence. The minimum proof for each audience. The internal team may get a signal right away. A consignee waits for a carrier confirmation. Billing waits for the POD rather than a "delivered" status.
Recipient. The roles that might hear about a load: the logistics team, customer service or sales, the shipper, the consignee, the receiving warehouse and billing. Each role gets the version it can act on.
The matrix is a company rule, but the contacts behind it belong to each shipment. One customer may want every change. Another wants only confirmed delays outside its receiving window. A third requires that a person approve any message to its buyers. Writing these rules down before the next late load means nobody decides them in a hurry, and the same event produces the same updates every time.
What verification looks like on a live load
Verification means a named carrier source confirmed the ETA and reason, and that confirmation sits on the shipment next to the update it supports.
The work starts with the best tracking source available for the load: the carrier API, GPS or ELD data where available, or the carrier website by PRO number. Those sources can raise or corroborate a delay. When they are stale, unclear or contradict each other, confirmation means contacting the carrier by email, or by phone where calls are configured.
Before a customer update goes out, the shipment should hold six things: the tracking event that raised the question, the carrier's confirmation, the reason, the corrected ETA, the shipment contact who will receive it, and a record of the notification itself. With all six attached, anyone who picks up the customer's call sees the same answer.
The recipient side needs as much care as the evidence side. Contacts should come from the shipment, not from a shared distribution list. Otherwise a confirmed ETA can reach the wrong account, a real risk for distributors who ship similar orders to competing customers. Keeping shipment status with the right customer is part of verification, not an afterthought.
ETAs also move more than once. Each new carrier confirmation re-enters the matrix, and recipients get an update only when the change matters under the company's rules.
Rules for holding, sending or escalating an ETA update
Each update gets one of three outcomes: hold it inside the team, send it to the configured recipients, or escalate it to a person.
Hold when the only evidence is a signal. Tell the logistics team the load is at risk and start verification. The customer hears nothing yet.
Hold when sources disagree. A carrier email and a tracking page with different ETAs must be settled before anyone outside the team hears either one. The rule for when a carrier email and tracking feed disagree settles which to trust while confirmation is pending.
Send a holding notice only if the company allows it. When delivery is near and confirmation is pending, some companies tell the customer the load is delayed, that a new ETA is being confirmed, and when the next update will come. The notice states facts and makes no new promise.
Send when confirmed. A carrier-confirmed ETA with a reason goes to the recipients the matrix names.
Re-send only on a material change. The company defines "material," for example any move outside the consignee's receiving window.
Escalate when the update creates a commitment. A new ETA that misses a promised date for a key account, or a message outside the standard rules, goes to a person before it goes out.
Escalate when the carrier can't confirm. The person gets the tracking events, every follow-up attempt and the decision needed.
Example matrix: who gets which update, and on what evidence
The matrix below is illustrative. The events are standard; the evidence bar and recipients should match each company's own rules and customer agreements.
Event | Evidence before release | Logistics team | Customer service or sales | Shipper | Consignee |
|---|---|---|---|---|---|
Booked | Carrier confirmation of the booking | Yes | Optional | Yes | No |
Picked up | Carrier status or pickup confirmation | Yes | Optional | Yes | Yes |
At risk | Tracking signal only | Yes | No | No | No |
Running late | Carrier-confirmed ETA and reason | Yes | Yes | Yes | Yes |
ETA changes again | New carrier confirmation | Yes | Yes | If material | If material |
Carrier can't confirm | Follow-ups recorded, no answer | Escalation | Yes | Holding notice if allowed | Holding notice if allowed |
Delivered | Carrier delivery status | Yes | Yes | Yes | Yes |
POD filed | Signed POD on the shipment | Yes | Optional | Yes | Yes |
How to use it. Take one recent late load and run it through the table. Check which updates each contact actually received and on what evidence. Gaps tend to show up in two rows: "at risk," where customers sometimes hear about unconfirmed delays, and "ETA changes again," where the second change often never reaches the consignee.
How Wilson, by Cartage verifies before it notifies
Wilson confirms a late load's new ETA and reason with the carrier, then notifies the people each shipment is configured to notify. Traditional logistics software gives teams information. Wilson executes the work required to move shipments forward.
Wilson tracks each load with the best source available. When a load runs late or the data can't be trusted, it emails the carrier, or calls carriers and drivers where calls are configured, to get the new ETA and the reason. The team hears in Slack or Microsoft Teams. The shipper gets email updates and the consignee gets email or SMS updates, as configured. By default, the consignee receives every event except booked. Each shipment carries its own contacts and rules, so updates follow the customer the load belongs to.
Customer notifications can be set to need approval, which many teams do while they review the first messages. Wilson starts with assisted execution, and the scope can grow step by step as the company gains confidence in the workflow. When a carrier can't confirm, Wilson escalates with what it already tried. Messages, confirmations and changes are recorded in the shipment's change history, so the evidence behind every customer update can be checked later.
If your team still checks with the carrier by hand before every customer ETA update, bring one customer's notification rules and a recent late load and walk them through the matrix with Wilson.
Sources
Cartage, Wilson product FAQ and product scope, October 2026: https://cartage.ai
Other latest news and success stories

January 25, 2022
Best AI Tools for Carrier Follow-Up in 2026
Read more →

January 25, 2022
Best Bill of Lading (BOL) Software for Manufacturers in 2026
Read more →
