Notifications your customers want (and the ones they mute)

Somewhere in most transport offices there is a customer who used to be told nothing and is now told everything. It usually happens after a complaint: something went wrong, nobody rang, and the fix was to switch messages on. Every status change now leaves the system and lands in that customer’s inbox. Booked. Planned. Assigned to a vehicle. In transit. Arrived at terminal. Delivered.

Three weeks later the customer has a mail rule that files all of it into a folder nobody opens — including the message that said the pallet had been refused at the dock.

That is the whole problem in one paragraph. Outbound notification is not a volume business. Every message spends a little of the reader’s attention, and the balance is invisible until it is empty.

The test to apply to every message

Before an event earns a notification, one question: would the person receiving this act differently, or worry less, for having it?

Not is it true, not is it interesting, not does the system know it. Acting or resting. A message that changes neither is not communication; it is your bookkeeping performed at somebody else’s desk.

The reason to be strict is not politeness. It is that unread messages are indistinguishable from one another. Once a customer has learned that your messages are usually nothing, the exceptional one arrives in the same folder, in the same font, and is read at the same speed — which is to say late, or never. Sending fewer messages is the thing that makes the important one land.

The four that earn it

Booked. The confirmation of what you believe you were asked to do. Its value is not “we have your order” — it is the correction window. Addresses, date, goods, references, the collection slot. Most of the errors that become expensive at the delivery end are cheaply visible here, but only if the message shows the details instead of announcing itself.

Collected. The first message that reports the physical world rather than an intention. The goods are with you, the customer’s own exposure has changed, and their part of the job is done. It is short and it is factual, and it is what stops the did you actually get it call.

Delivered. With the proof, not a promise of proof. The time, who signed, and a way to obtain the document without asking a human for it. A delivered message carrying nothing but the word “delivered” generates the email asking for the POD, which means you sent a message in order to create work.

A problem. Anything that breaks the plan the reader is holding: a failed delivery, a refusal at the gate, damage, a delay long enough to change what they will do about it. This is the message the relationship is judged on, and it is the one most operations send worst — late, after it has been resolved internally, and phrased to explain rather than to inform.

What the four have in common is that each one hands the reader a decision or closes one. Everything between them is your operation talking to itself.

The ones that get muted

• Internal state changes. Planned, assigned, dispatched, arrived at terminal, re-planned. These describe your work, not their goods. A tour re-planned three times in an afternoon is three messages reporting that nothing has changed for the recipient.
• The same event on two channels. An SMS and an email for one delivery is not twice the certainty; it is the second one teaching the reader that your messages are duplicates and can be skimmed.
• Heartbeats. “Your shipment is still in transit.” Nothing has happened, and nothing having happened is not news.
• Messages that do not contain the answer. “There is an update on your shipment — log in to see it.” That is a notification about a notification, and it costs the reader more than it gives them.
• Messages to a list. Booker, accounts and the receiving site copied on everything dilutes ownership: each assumes one of the others is dealing with it, and the reply you needed does not come.

Getting the four right

• Say it in the subject line. The reader should be able to act, or decide not to, without opening the message. Delivered 14:20, signed R. Nilsson, your order 4471 is a complete communication. Shipment update is a request that they do the work of finding out.
• One event, one message, one recipient who can act on it. The others get access, not alerts. Copy the accounts contact on the invoice, not on the collection.
• Carry the reader’s own reference. Your booking number means nothing on the far side of the desk. Their order or purchase-order number is what their filing keys on, and including it is the difference between a message that gets filed and one that comes back to you asking which shipment this is.
• Stamp it with the time it was true, not the time it was sent. A batch going out at 18:00 containing a 10:40 delivery is honest if it says 10:40 and misleading if it does not — the same discipline that makes an ETA worth quoting.
• Pick the channel from the deadline for acting. Push or SMS for what the reader must handle within the hour: a refusal, a driver at a locked gate, a delivery that will not happen today. Email for what is wanted as a record rather than as an interruption. Almost nothing needs both.
• Let them switch things off, per event type, and then read the result. An opt-out is not a loss. It is the only honest data you will get on which of your messages were noise, and if half your customers mute collected, that is an answer worth having.

What notifications cannot do

They are push, and push is bad at questions. A notification tells someone that something happened; it cannot answer where is the load I am thinking about right now or send me Tuesday’s POD again. Those need a place to look, which is a different thing to build, and the reason a portal removes calls that messages do not.

They also amplify whatever is wrong with your data capture. The usual damage is a “delivered” that fires when the driver closes the whole run at the depot at half past six, stamping four deliveries with one time. Internally that is a small inaccuracy in a record. Sent out, it is four provable untruths, and the customer who signed at 10:40 now knows exactly what your timestamps are worth. Fix where the event is captured before you broadcast it.

And silence has to mean something. If you notify on four events and nothing else, then “no message since collection” must reliably mean “nothing has gone wrong” — which is only true when the problem message is emitted from the record automatically rather than by whoever remembers to send it. An operation that reports good news reliably and bad news manually has taught its customers to ring anyway, which is where this started.

Start by receiving your own

Subscribe yourself as though you were a customer, on a real account, for a week. Read the messages on a phone, in the order they arrive, without the context you have from sitting inside the operation. Two things usually turn up: several messages that say nothing at all, and one moment where you wanted a message and got none.

Then ask two customers — the one who rings most and the one who never rings — which of your messages they actually read. The answer rarely matches the list you would have guessed.

Where navichain stands

navichain sends shipment notifications into the customer’s own portal, scoped to their organization, alongside the shipments they book and track themselves on web or in the app and the documents, proof of delivery and invoices they take self-serve — so the routine questions are answered by a place to look and the messages can stay few. Internally the same discipline applies: the right person is told, in the app, by push or by email, and nobody else is pinged. None of it is a paid add-on — all features are on every plan, and you pay for scale rather than capabilities. The platform page shows what is inside and pricing what it costs.