Which channel should carry a delivery notification?
The channel follows the recipient's country and the message's job rather than a company-wide preference, which is why most operations end up running two channels rather than picking one. Three constraints decide which carries a given notification: where the recipient is, whether you need a guaranteed floor, and what the message has to carry.
Where the recipient is. Messaging-app penetration is regional, and the same notification belongs on different channels in different markets. NUJEK made WhatsApp the main communication channel between its support team and its customers in Indonesia, on the reasoning their team stated plainly: WhatsApp is the number one messaging app used in Indonesia. That is a market fact about Indonesia, and the same logic points elsewhere in markets where SMS or another channel dominates.
Whether you need a guaranteed floor. SMS reaches a handset without an app installed, an account, or a prior conversation. That makes it the fallback rather than the default: the channel you fail over to when the richer one is unavailable for that number or that country.
What the message has to carry. A tracking link and a delivery window are text. A photo of a doorstep drop, a signature capture, or a map pin are not, and a channel that cannot carry them forces the recipient into a browser.
A pattern worth naming, because it is the one most logistics teams converge on: a rich channel as the default where it is available, SMS as the fallback, and one identity for the customer across both so a reply on either lands in the same conversation.
One precision that matters when you build the fallback. The delivery event vocabularies are not symmetrical. Bird publishes seven WhatsApp event types (whatsapp.accepted, whatsapp.sent, whatsapp.delivered, whatsapp.read, whatsapp.received, whatsapp.failed, whatsapp.rejected) and twelve for SMS, which add sms.undelivered and sms.expired. If your fallback logic waits for an expiry signal that the richer channel never emits, it will wait forever. Branch on the vocabulary each channel actually publishes.
What has to be in the template before WhatsApp approves it?
On WhatsApp, a business-initiated message runs through a template that Meta reviews, and the category you file it under governs more than the wording. Bird's template documentation states that the category governs how WhatsApp treats the message, which Bird number a managed template sends from, and, with the destination country, the price.
Meta's three categories are authentication, utility, and marketing, and for delivery notifications the answer is almost always utility, which covers order updates, appointment reminders, and account notices. Two consequences follow, and they are the reason to get the category right the first time:
- Utility templates have the fewest prerequisites of the three. Authoring an authentication template of your own needs a verified business; marketing templates always send from a WhatsApp Business Account of your own and carry an opt-out expectation.
- Miscategorising a notification as marketing changes the price and the obligations. A delivery update filed as marketing inherits the marketing category's business-account requirement and its opt-out expectation, for a message the recipient asked for by placing an order.
The operational habits that reduce rejections, in the order they pay off:
- Write the variables as variables. A template with the tracking number hard-coded is a template you resubmit per shipment.
- Version rather than recreate. A rejected template that is deleted and re-authored loses its history. Submitting a new version of the same template keeps the record of what was rejected and why.
- Read the rejection before resubmitting. A template rejected for a category mismatch gets the same answer until the category changes.
- Keep a language per market. A template stocks languages; a per-market template set that duplicates the same content is a maintenance cost with no benefit.
What happens when the customer replies?
This is the question that decides whether the programme saves money or costs it, and it is the one most often planned last. A notification invites a reply by its nature, so inbound volume scales with the send, and each reply lands in a channel the recipient now treats as a support line.
Where is my parcel, can you leave it with a neighbour, can I change the address. Sending 500,000 notifications a month means receiving a meaningful fraction of that back.
Aramex is the clearest published case of designing for this rather than absorbing it. A global logistics and transportation provider with 18,000 employees and offices in over 70 countries, Aramex handles 500,000 WhatsApp messages every month and reached 2.7x productivity, and their stated mechanism was to direct customers to solve issues on their own before talking with an agent. The productivity figure follows from the deflection design.
Three components make that work, and all three have to exist before the first send:
- An inbound route. A reply has to reach something. An inbound message with no handler is a customer talking to a wall, which is worse for satisfaction than not having sent the notification.
- Self-service first. The common questions have deterministic answers drawn from the shipment record. Answering them without a human is what turns notification volume into deflected support rather than added support.
- A path to a person. Deflection that cannot escalate is a trap. The cases that need an agent need to reach one with the conversation history attached.
Bazaar, a marketplace rather than a carrier, reports the same shape at 284,000 WhatsApp messages a month with an 85% AI resolution rate. Both figures are those companies' own results in their own operations, and neither is an industry benchmark, but they agree on the design: the automation sits on the reply path, not the send path.
Do notifications only go to recipients?
No, and this is the part a delivery-notification project usually scopes out and later regrets. A logistics operation has at least three audiences on the same channel, and the courier and partner sides are often where the measurable gain sits.
Glovo, an on-demand delivery app for meals, groceries, and other local orders, improved partner onboarding by 4x with WhatsApp. That is not a consumer notification result. It is the supply side of the network, and it moved a number that consumer notifications do not touch.
The three audiences, and what each needs:
- The recipient, who wants the parcel's status and a way to change something about the delivery.
- The courier or driver, who needs assignment, route, and exception handling, usually while moving and often on a personal device.
- The partner, merchant, or franchise, who needs onboarding, documentation, and account notices. NUJEK's stated use covered courier and partner communications alongside customer support.
Each audience is a different template set and a different reply path, and they do not share consent. A driver's operational messages are not covered by a recipient's transactional expectation.
What should I measure?
Delivery rate alone will make a failing programme look healthy, because a notification that arrives and generates a support call has still arrived. Four measurements matter, and the one most programmes lack is the reply rate per notification type, which tells you whether the wording is working or quietly costing you agents.
Four measurements, in the order they change decisions:
- Delivery and read, per country and per template. An aggregate figure hides the market where the channel is failing. Break it down by the dimensions that vary, which are country, template, and channel.
- Reply rate per notification type. This is the deflection metric's denominator. A template with an unusually high reply rate is a template whose wording is unclear, and it is cheaper to fix the wording than to staff the replies.
- Self-service resolution share. What fraction of inbound resolves without an agent. This is the number Aramex's 2.7x productivity is a downstream expression of.
- Cost per notification, split. Meta's conversation fee and your provider's fee are different numbers with different drivers. Bird records the passthrough portion and the platform portion separately rather than merging them, which is what lets you model a channel switch.
What not to measure as a headline: total messages sent. It grows with shipment volume regardless of whether the programme is working, and it is the number most likely to be reported as success.
What breaks first when volume grows?
Four failure modes, ordered by how commonly they are hit. None of them appears at pilot volume, which is what makes them expensive: each surfaces as a gradual rise in support load or a per-country gap rather than as an error your monitoring would catch.
Per-country availability changes underneath you. Which channels can reach which countries, and what registration each requires, is live policy rather than a static list. Bird renders a page per country for exactly this reason, and treating it as configuration to re-check beats treating it as a fact learned once.
Consent and opt-out handling gets bolted on. A recipient who opts out of delivery notifications has opted out, and honouring that has to be a property of the sending path rather than a suppression list someone maintains by hand. Get it wrong at 500,000 messages a month and the volume is the problem.
Webhook handling assumes ordering. Delivery events are not guaranteed to arrive in the order the states occurred. A handler that overwrites status on each event will report a delivered parcel as sent when two events cross.
One template set is stretched across markets. The template that works in one market carries the wrong tone, the wrong address format, or the wrong support hours in another. This surfaces as a rising reply rate in one country rather than as an error, which is why the per-country breakdown in the previous section is worth building before you need it.