Test customer notifications with a late load, not an on-time one
Key Takeaways
- An on-time load only proves a notification tool can send "picked up" and "delivered." A late load tests whether it can get a new ETA, explain why and tell the right people.
- Script the delay before the test: the late signal, the carrier's reply, a second ETA change, an unanswered follow-up and a truck that can't make it.
- Score every message on four points: who received it, when, through which channel, and whether it carried the reason and the new ETA.
- Seeing that a load is late is visibility. Getting the carrier's answer, notifying stakeholders and recovering or escalating is execution, and the test should cover both.
- Wilson, by Cartage, gets the new ETA and reason from the carrier, notifies the stakeholders each company configures,, then recovers or escalates under its rules.
Why does a late load make a better notification test than an on-time one?
Because an on-time load only exercises scheduled messages. A late load forces the software to find out something new, decide who needs to know and say it clearly, which is the part your customers actually judge.
On an on-time load, every event fires in order and a template fills itself in. Almost any tool passes. A late load is different. The software has to notice the problem, ask the carrier, wait for an answer, read a reply that may be vague, choose recipients and keep the message consistent when the ETA moves again.
That's where notifications go wrong. The consignee gets a message with no new time. The shipper hears nothing because only the internal channel was configured. A second slip never reaches the customer who received the first ETA. An internal note about rebooking costs lands in a customer's inbox.
You already know what a good delay message says; a delayed delivery needs a customer update lays out its parts. The test below checks whether the software produces that message itself, for the right people, without a coordinator writing it.
How do you script the late load before the test starts?
Write the scenario down before anyone opens the software, so every tool you evaluate faces the same delay.
Pick a real load from recent weeks. Use the actual lane, an approved carrier, the shipper and consignee, and the delivery appointment.
Replace customer contacts with test addresses. Use internal email addresses and phone numbers that stand in for the consignee and shipper.
Write the stakeholder map. For the "running late" event, list who should hear, in what order and by which channel: for example, the internal team in Slack or Microsoft Teams, the shipper by email, the consignee by email and SMS.
Script the carrier's behavior. Someone on your side plays the carrier and replies at set points: a first answer with a new ETA and reason, a second revision, one follow-up left unanswered, and finally a message that the truck can't make it.
Set the rules you'd actually use. Whether customer notifications need approval, how many unanswered follow-ups come before escalation, which approved carriers are eligible for rebooking and the cost threshold above which a person decides.
Write the expected outcome for each step before the test runs.
What should you watch while the delay plays out?
- First carrier contact. How long after the late signal did the software ask the carrier, and through which channel? Flagging the load and waiting for a coordinator is visibility, not execution.
- What it held back. Before the carrier answered, did customer-facing contacts receive a guessed ETA, or nothing, or a provisional notice your rules allow?
- Message content. Each customer message should carry the reference the customer uses, a new ETA as a window, a short reason and when the next update will come.
- Internal versus external. Rebooking options, carrier performance and cost impact should reach the team only.
- The second change. When the ETA moves again, the same recipients should get the correction, and the shipment record should show which ETA is current.
- Silence. When the carrier stops answering, the software should retry on the next configured channel, then escalate after the number of attempts your rule allows.
- Recovery. When the truck can't make it, rebooking should start from approved carriers only, run within the rules or wait for approval, and escalate if no approved carrier accepts.
How do you judge the results: pass, fail and the gray areas?
Automatic fails:
- A configured stakeholder received nothing for a step where your map said they should.
- Someone outside the map received a message.
- A customer message claimed a new ETA the carrier hadn't given.
- The second ETA change didn't reach everyone who got the first.
- An escalation arrived without the history: what the carrier said, what was tried and what decision is needed.
Gray areas to settle in advance:
- Provisional notices. Acceptable if your rule allows them and the message says the ETA is being confirmed.
- Approval wait time. If customer notifications need approval, time spent waiting for a person reflects your setting, not the software's speed. Measure it separately.
- Timing. Judge against your own rule for how fast a customer should hear, not a vendor's average.
If your delays often happen after hours, rerun the same script at night; who follows up on late loads overnight and on weekends covers the escalation rules that run then. For the wider sequence after an alert fires, see what happens after an exception alert.
A late-load notification test script
Times are illustrative. Use your own load and appointment.
| Step | What you script | Expected behavior | Pass if |
|---|---|---|---|
| 1. Setup | Load due Thursday 10 a.m.; test contacts for team, shipper and consignee | Recipients and rules loaded before the delay starts | The configuration shows who gets "running late" for this customer |
| 2. Late signal | Wednesday 3 p.m.: tracking shows the load behind schedule | Software contacts the carrier for a new ETA and reason | The carrier request is recorded; no customer gets an unconfirmed ETA |
| 3. Carrier reply | Carrier: held at terminal, new ETA Thursday 2–4 p.m. | Team notified, then shipper and consignee per the map | Each message has the PO, ETA window and reason; no internal notes reach customers |
| 4. Second slip | Carrier revises to Friday 9–11 a.m. | Correction sent to the same recipients | Same audience; earlier ETA marked as replaced |
| 5. Silence | Carrier ignores the next follow-up | Retry on the next configured channel, then escalate | Escalation reaches the team with the history attached |
| 6. Can't make it | Carrier says the truck won't run Friday | Rebooking from approved carriers within the rules, or escalation | No unapproved carrier; anything above the threshold waits for approval |
| 7. Close | Replacement load delivers; POD arrives | Delivered and POD updates to configured recipients | Shipment history shows every message in order |
Run it twice: once with prompt carrier replies, once with step 5 stretched out.
How does Wilson, by Cartage handle the late-load script?
Wilson is an AI logistics agent that replaces the TMS for freight execution; it is not a standalone visibility platform.
Wilson tracks each load with the best source available: the carrier's API, GPS or ELD data where available, or the carrier's website by PRO number. When a load runs late, it gets the new ETA and reason from the carrier, by email or by phone where calls are configured, and follows up when the carrier doesn't answer. It then notifies the stakeholders the company has configured: the internal team in Slack or Microsoft Teams, the shipper by email, and the consignee by email or SMS.
If the carrier can't make it, Wilson initiates rebooking from the customer's approved carriers, automatically within the rules or after approval, depending on configuration. When no approved carrier accepts, or a decision falls outside the rules, it escalates to the team. Wilson starts with assisted execution, so customer notifications and rebookings can require approval while the team reviews the results. Messages, confirmations and changes are recorded in shipment history, which is what you score step 7 against.
Bring one load that ran late last month, with the contacts who should have heard about it, and watch Wilson run your late-load script against it.
Sources
- Cartage, Wilson product FAQ and product scope, October 2026: https://cartage.ai