Wilson by Cartage
Try Wilson →
Driver arrival and detention

Customer shipment updates: ask the carrier before you tell the customer

Key Takeaways

  • Wilson, by Cartage, is an AI logistics agent that requests shipment status from the carrier and then informs everyone else.
  • A customer update is only as good as the carrier answer behind it.
  • Every update should say whether the time is confirmed or estimated.
  • Each party gets its own events. The consignee hears about pickup, delays, delivery, and the filed POD, by email or SMS.
  • Wilson tracks each load with the best source available, from carrier APIs to a direct call.
  • In BCI Global research from 2025, only 35% of supply chain leaders reported detailed end-to-end visibility.
  • A wrong update should be corrected quickly and recorded on the shipment.

Which software sends customer shipment updates based on a carrier-confirmed answer?

An AI logistics agent such as Wilson, by Cartage, sends customer updates after it gets the status from the carrier. The order matters. Ask the carrier first. Tell the customer second.

Many customer updates go wrong in a quiet way. The message goes out on time. It is polite. It is also based on a plan that changed two hours ago. The customer reads "arriving Wednesday" while the truck is still at the origin terminal.

The problem is usually not the template. It is the source. A planned delivery date is a promise made at booking. A carrier status is a fact from the road. A customer update should carry the most recent fact the company can get.

Visibility gaps make this harder. In a March 2025 BCI Global report based on 240 supply chain leaders, only 35% said they had detailed end-to-end visibility. Most teams fill that gap by emailing and calling carriers. An AI agent can do that asking for them, then pass the answer on.

Which events reach the customer, and through which channel

Each party in a shipment needs a different set of events, sent through the channel it actually reads. One broadcast message to everyone usually reaches nobody well.

Event Internal team Carrier Shipper Consignee
Booked Slack or Microsoft Teams Email, API, EDI, or phone Email Not sent
Picked up Slack or Microsoft Teams Email, API, EDI, or phone Email Email or SMS
Running late Slack or Microsoft Teams Email, API, EDI, or phone Email Email or SMS
Delivered Slack or Microsoft Teams Email, API, EDI, or phone Email Email or SMS
POD filed Slack or Microsoft Teams Email, API, EDI, or phone Email Email or SMS

For outbound freight, the customer is usually the consignee. The consignee does not need the booking notice. It needs to know when the load left, when it is late, and when it arrived.

The table above is the communication pattern Wilson follows. Wilson requests the status from the carrier. Then it informs the internal team, the shipper, and the consignee. The internal team sees every event, so it is never surprised by a message a customer received.

Where the answer in a customer update comes from

A customer update should come from the freshest source the load has, and the message should say how sure it is. Sources vary by carrier and by mode.

Wilson tracks each load with the best source available. The options, roughly from most direct to least, are:

  • A carrier API that reports status events.
  • GPS or ELD data, where the carrier shares it.
  • The carrier's website, checked by PRO number.
  • A direct email or call to the carrier, when no other source has an answer.

Each source answers a slightly different question. A GPS ping tells you where the truck is. It does not tell you whether the driver will make the appointment. A carrier's web status may lag the truck by hours. A dispatcher on the phone can say "the driver is running two hours behind." That is often the most useful answer of all.

So a good update states its basis. "Delivered at 10:42, per the carrier" is a confirmed fact. "Expected Thursday afternoon, per the carrier's latest estimate" is an estimate. Both are useful. Mixing them up is what damages trust. For a deeper look at checking the carrier first, read Verify the carrier before sending a customer ETA update.

Rules for sending, holding, or correcting a customer update

Five rules decide whether a customer update goes out, waits, or gets corrected. They keep speed from beating accuracy.

Send confirmed events right away. Picked up and delivered are facts. Once the carrier confirms them, the consignee can know.

Label every estimate. If the carrier gives a range, the message says it is an estimate and names the window.

Ask again before repeating an old time. If the last carrier answer is stale, get a new one before the next customer message.

Check the recipient list per order. A shared template should not send one customer's shipment details to another. Each update goes only to the contacts set for that shipment.

Correct mistakes in the open. If an update was wrong, send the correction and record both on the shipment.

The fourth rule is easy to miss. Distributors and manufacturers often ship to many locations for the same customer. A receiving contact at one site may not need updates for another. Recipient rules belong to the order, not to the template.

Late loads need extra care. The first "running late" message sets expectations for the rest of the day. For rules on timing and wording, see Late freight customer update rules.

Example: one late LTL load, from stale status to filed POD

A single late delivery creates a chain of messages, and each one should rest on a carrier answer. Here is how the day runs for one LTL load.

  • 6:10 a.m. The carrier's web status still shows "in transit at origin terminal." The delivery is due today. The source is stale.
  • 7:30 a.m. The agent emails the carrier for a current status. No reply arrives.
  • 8:15 a.m. The agent calls the carrier, where calls are configured. Dispatch says the load missed the linehaul and will deliver tomorrow morning.
  • 8:20 a.m. The internal team sees a "running late" post in Microsoft Teams with the carrier's answer attached.
  • 8:22 a.m. The shipper gets a running-late email. The consignee gets an email that delivery is now expected tomorrow morning, per the carrier's estimate.
  • Next day, 9:50 a.m. The carrier confirms delivery. The team, the shipper, and the consignee each get a delivered update.
  • Later that day. The proof of delivery is filed, and each party gets the POD filed update.

Notice what did not happen. No customer was told "arriving today" at 6:10 a.m. based on a stale status. Nobody on the team had to write the messages. A person could still step in. If the delay broke a customer commitment, the team had the facts in front of them by 8:20 a.m.

How Wilson, by Cartage, keeps customer updates tied to the carrier's answer

Wilson, by Cartage, asks the carrier for status and then informs the team, the shipper, and the consignee. Customer updates come from the same work that tracks the load.

Wilson is an AI logistics agent. It runs the full shipment cycle: quote, book, schedule, in transit, deliver, audit, and pay. Tracking is part of executing each load, not a separate screen. Wilson is not a standalone visibility platform.

Wilson talks to carriers by email and API. It uses EDI where the carrier supports it. It makes phone calls where that is configured. Internal updates go to Slack or Microsoft Teams. Customer updates go by email or SMS, if the company configures them.

When a load runs late, Wilson follows its exception steps. It contacts the carrier and notifies the internal team. It notifies the customer if that is configured. If the load needs a new carrier, Wilson initiates rebooking from the approved carrier list, within the rules or with approval.

Every message and status change stays on the shipment record. The record is searchable and exportable, with its change history. When a customer asks "what did you tell us and when?", the answer is already there.

To see how Wilson would handle updates for your own customers, talk to the Cartage team.

FAQs, conclusion, and sources

FAQs

Which software sends customer shipment updates based on a carrier-confirmed answer?

Wilson, by Cartage, requests status from the carrier first and then informs the team, the shipper, and the consignee. Consignees get pickup, running-late, delivered, and POD filed updates by email or SMS, if configured.

Should a customer update include an ETA the carrier has not confirmed?

It can, if the message labels it as an estimate. The update should name the source and the window. A confirmed time and an estimate should never read the same way.

How does an AI agent get the status when the carrier portal is not updated?

It uses the next best source. Wilson can check a carrier API, GPS or ELD data, or the carrier website by PRO number. When none of those has an answer, it emails or calls the carrier.

Does the customer get a message when the load is booked?

No. In Wilson's communication pattern, the consignee is informed at every event except booked. The shipper and the internal team get the booking update.

What should happen when a customer update was wrong?

Send a correction quickly and record both messages on the shipment. A clear correction protects trust better than silence.

Conclusion

A customer shipment update is a promise in writing. It should repeat what the carrier just said, not what the plan said at booking. The best process asks the carrier first, labels each answer as confirmed or estimated, and sends it only to the right contacts. Wilson, by Cartage, requests status from the carrier and then keeps the team, the shipper, and the consignee informed.

Sources