WhatsApp for logistics and delivery businesses
“Where is my parcel” is the highest-volume, lowest-value question in the industry, and it is currently answered by drivers on the road. Automating the routine half is worth more than any marketing message you could send.
“Where is my parcel” is the highest-volume and lowest-value question in logistics. It is currently answered by drivers at the roadside, by an office that has to phone the driver, and by customers who message three times because nobody replied to the first.
It is also almost entirely answerable from data you already hold.
The economics
| What it costs now | |
|---|---|
| Driver answering while driving | Unsafe, slow, and the answer is often wrong |
| Office relaying between customer and driver | Two calls per enquiry, neither adding information |
| Customer messaging repeatedly | Because the first message went unanswered |
| Failed delivery, nobody home | The whole trip, repeated — the most expensive event you have |
| A tracking page nobody opens | Built, paid for, and less used than a WhatsApp reply |
The failed delivery is the one worth designing around. Almost every failed delivery was preventable with one message an hour beforehand asking whether somebody will be there — and that message is the cheapest thing on this page.
Two halves
Proactive: tell them before they ask
- Collected — we have it, here is the reference.
- In transit / arrived at the depot — only if the leg is long enough to matter.
- Out for delivery, with a window — the highest-value message you send.
- An hour before arrival — and asking whether somebody will be there.
- Delivered, with who signed — closes the loop and prevents a dispute.
- Failed, with what happens next — the one nobody sends, and the one that most needs sending.
Each of these removes enquiries rather than creating them. That is the test for whether a notification belongs in this list.
Reactive: answer the ones that still come
Status by reference number, expected window, delivery address on file, what to do if nobody will be home, how to redirect. All of it from your own system, which means the agent needs to reach it — a tool call into your tracking API rather than a document.
What it must not do
What it looks like
That exchange prevented a failed delivery, which is the expensive event, and it did it without a driver, an office call, or a customer waiting in for four hours.
Setting it up
1. Connect it to your tracking system
This use case is unusual on this site: documents are not enough. The agent needs a tool that looks up a reference and returns real status. Everything above depends on that being live rather than a description of how tracking works.
2. Define what a reference is, and validate it
Customers type them wrong, with spaces, with the wrong prefix. Handle that gracefully — “I can’t find 8492O, did you mean 84920?” saves an escalation.
3. Route exceptions to somebody who can act
A damaged parcel or a missed delivery needs a person with authority to fix it, not a general inbox. See shared inbox for getting it to whoever is free.
4. Send the pre-arrival message and measure it
Compare failed-delivery rates on routes that get it against routes that do not. This is the number that justifies the whole project, and it is easy to measure.
A note on volume
Logistics is the use case most likely to outgrow a connected number. Thousands of notifications a day to people who mostly do not reply is exactly the shape Meta’s official platform is engineered for, and exactly the shape that stresses an ordinary account.
If you are sending at that scale, read the comparison honestly — this may be the case where the official API is the right answer and we are not.
Common questions
Can the agent answer from my own tracking system?
It needs to. Documents describe how tracking works; answering "where is 84920" requires a live lookup against your system, so this use case depends on connecting a tool rather than uploading a file.
Will it reduce failed deliveries?
That is the largest measurable saving available here. One message an hour before arrival, asking whether somebody will be there and offering alternatives, prevents the trip that otherwise has to be repeated. Measure it by route to see the effect.
Should I send an update at every scan?
No. Every notification should remove an enquiry rather than create one, and a depot scan at 3am does neither. Collected, out for delivery, about to arrive, delivered, and failed are the ones that earn their place.
Can it tell anyone where a parcel is going?
It should not. A reference number is not proof of identity, and confirming a delivery address to whoever quotes one is a safety problem rather than a customer service decision.
Is WhatsApp suitable at high volume?
Up to a point. Thousands of notifications a day to people who rarely reply is the shape Meta’s official platform is built for, and it stresses an ordinary connected number. At that scale the official API is likely the better answer.