A delivery notice is not a mail. A dispatcher writes it by hand. It is an output. From three sources. The order in the TMS. The route plan. The telematics ETA of the truck. Today the dispatcher still writes it herself, almost everywhere. By hand. From memory. That is the actual mistake.
My thesis: delivery notification automation does not fail on technology. The three sources already exist, most of the time. It fails on a question. Nobody has answered as a data record. The real problem is the receiver rule. Who wants the notice how? When? In what format?
A notice is the advance announcement of a delivery. Time window. Shipment data. Often a plate number. A German logistics glossary lists three channels. By phone. In writing. Digital. Digital mostly means: mail, portal, or an EDI message.
A trade article on digital truck notification lists the usual fields. Delivery date, delivery time. Item, quantity, weight, volume. Dock notes. EDI formats add shipment and packing data. Each field comes from a different system. The time window comes from route planning. Quantity and weight come from the order. The time, if it is honest, comes from telematics. Not from yesterday's schedule.
That is the first technical task. Three systems. One receiver. One message. The order gives the what. The route plan gives the who. And the sequence. Telematics gives the when. Live, not planned.
The message itself is the easy part. The hard part is the path. An industrial receiver often demands a mandatory time slot booking. Through its own portal. A delivery policy from an industrial site, dated November 2025, states it plainly. Registration only through the booking portal. Mail, fax, or phone are usually not allowed. Without a booking, the site can refuse the delivery.
Another receiver wants the opposite. A short mail. Twelve hours ahead. A third wants a phone call. The dock is small. The foreman decides himself. Three receivers. Three rules. With twenty receivers, that is often twenty rules.
That rule is a master record. Channel. Format. Lead time. A contact, if the channel is a phone call. In most carriers, this record lives nowhere. It lives in the head of one dispatcher. Who has served that customer for five years. If she is out, nobody notifies correctly. That is the real master data problem. Not the mail template. Not the portal login itself.
Once that rule exists as a record, the rest is a routing problem. Portal receivers get a portal agent. As described for customer portals without an API. Mail receivers get a mail. Built from order, route, and ETA. Phone receivers land as a task in a calendar. With a ready script. Instead of a search in the TMS.
A notice that stands once is only half the work. A German article on time slot management describes the core problem. A booked slot expires on delay. The booking was for a time. Not for the truck.
For automatic arrival notification from telematics, a coarse read interval is enough. A parked truck does not go stale. For a notice, the opposite holds. The ETA keeps changing. As long as the truck moves. If it slips past a threshold, say thirty minutes, the receiver needs a new message. No person should have to check that. One comparison is enough. Planned arrival against current ETA. Every few minutes.
The same holds for a redispatch. If the truck changes, the plate number in the notice changes. If the route order changes, the time changes. For dispatch, that is one click in the TMS. For the receiver, it is a new notice. That link is missing almost everywhere today. Dispatch reassigns the load. The old notice just sits there. Until someone notices. Often the receiver. At the gate. When the wrong truck shows up.
An automation that sends mail to customers on its own needs hard limits.
First: no notice without a confirmed route. A planned but unreleased route is not a reason to send. Otherwise the system announces a delivery that ends up running differently. Or not at all.
Second: a test mode. It keeps real runs apart from test runs. New receiver rules run against test addresses first. Before the first real customer gets a notice.
Third: a log per notice. Sent. Accepted. Failed. Not just that the pipeline ran. What happened for each receiver. For a portal receiver, the log shows the login and the confirmation screen. For a mail, the timestamp. And, where available, delivery status. For a phone receiver, the dispatcher's completed checkbox.
Without that log, a complaint is hard to settle. "The notice never arrived." With the log, it is one line to check.
For dispatch, the day changes at the point that used to take the most time. Writing and updating the notice, on every change. The route gets planned. The notice follows on its own. What remains is the edge case. A receiver with no stored rule. Or a portal login that fails technically.
For customer service, the type of question changes. "Where is the notice" mostly disappears. The log already holds the answer. What remains are content questions. Wrong quantity. Wrong time window, because the order itself was wrong. A smaller problem than today.
Dwell time drops, indirectly. A slot updated in time does not expire. The truck does not have to rebook. And wait. Wrong deliveries drop too. The format matches the receiver. Not whichever template was closest at hand.
Three honest limits.
Not every receiver fits into a rule. Some want to decide case by case. Depending on the dock's load that day. Then a phone call is the right answer. Not the worse one.
Not every delay needs a report. A thirty-minute threshold is an assumption. Not a standard. It needs tuning per receiver and route type. Otherwise there are too many re-notices. Or too few.
A receiver master record does not replace contract management. If a customer changes its notice rule, someone has to enter that. An agent can fill the field. It cannot know the rule changed. Not before someone tells it.
A receiver master record with channel, format, and lead time. A block that merges the TMS order, the route, and the telematics ETA into one message. A threshold comparison for a re-notice. On delay and on redispatch. Three guards: confirmed route, test mode, a log per notice. None of this is exotic. What is new is that it exists for every receiver. Not only for the three biggest customers.
How many of your customers' notice rules live only in one person's head? In dispatch? Send me the number. Then I will show you, in a process check, what the receiver master record looks like for exactly those cases.
