> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Retail notifiable events: SMS vs WhatsApp

> A tenant-owned checklist for choosing the channel that carries retail notification events — order confirmations, shipping updates, delivery alerts, and exception notices — scored SMS against WhatsApp on reach, rich content, delivery evidence, cost shape, and fallback behavior.

# Retail notifiable events: SMS vs WhatsApp

A **notifiable event** is a machine-triggered retail moment — an order confirmation, a shipping update, a delivery alert, or an exception notice (delayed, failed attempt, refunded, cancelled) — that your commerce or order-management system emits and your messaging platform turns into a one-to-one transactional send. This page scores the two channels that carry those sends most often, SMS and WhatsApp, on the facts a retail buyer can verify about either channel before wiring the events to a first-choice channel.

The decision is rarely one-channel-forever: pick the first-choice channel per event stage, then wire the fallback the corpus expects you to run anyway. SMS-first and WhatsApp-first are both defensible defaults; the checklist below tells you which axes pushed you to one of them.

## 1. Gaps buyers hit first

* **Assumed-first-choice channel hard-coded.** The event pipeline sends `order.shipped` to WhatsApp because "everyone has WhatsApp" — or to SMS because "we started there" — without per-recipient evidence either channel actually lands. The gap shows up as a quiet delivery-rate gap per stage that a campaign dashboard never catches.
* **No read evidence on the transactional path.** Order confirmation lands on SMS with a delivered receipt, but nobody can tell whether the customer ever opened it. WhatsApp returns read receipts; SMS usually does not, so the channel choice decides how much evidence the ledger shows.
* **Rich-content wishes on a plain-text channel.** A delivery alert that could carry a tracking short-link and a photo of the parcel goes out as 160 plain characters because the first-choice channel is SMS. That is a content-shape mismatch, not a routing fault.
* **Fallback never wired.** The first-choice channel 404s on a recipient (number not on WhatsApp, SIM off-market) and the event dies there instead of dropping to the second channel — a silent loss your exception stage would have shown.

Orbit closes these by treating channel choice per stage as tenant configuration: wire the [fallback chain](/guides/fallback-channels-recipe) so a missed first-choice channel drops to the other, and read the actual per-stage outcome in the [order notifications ledger](/guides/order-notifications-ledger).

## 2. Tenant-owned checklist rows

Score the two channels on five rows you can verify about either, at the published product surface, before committing a stage to a first-choice channel:

* **Reach on the recipient's handset.** SMS reaches any numbered handset that can accept a text. WhatsApp reaches only recipients who run the app and have agreed to receive your messages — a materially smaller subset that varies by country and by your own list.
* **Rich-content shape.** WhatsApp carries media attachments, delivery photos, signed-for receipts, and structured buttons. SMS carries text plus a tracking short-link; the richer the event wants to be, the more SMS pushes that content onto a landing page.
* **Delivery + read evidence.** Both channels return a delivered receipt into the [ledger](/guides/order-notifications-ledger). WhatsApp additionally returns a read receipt, so the confirmation stage can show whether the customer actually opened the message.
* **Cost shape.** SMS bills per segment; WhatsApp bills per conversation. At retail-notification volumes the per-event cost differs by market and template, so the correct comparison is the [rate card](https://orbit.devotel.io/pricing) against your actual stage mix, not a published average.
* **Fallback behavior.** When the first-choice channel refuses a recipient, the event should drop to the other channel rather than fail closed. Orbit's [fallback chains](/guides/fallback-channels-recipe) make that a per-chain tenant decision, not a per-send guess.

## 3. Scored candidates

Score each channel "yes / partial / no" per row at the level the product surface publishes; a blank cell reads as missing research.

| Checklist row                    | SMS-first                                                         | WhatsApp-first                                                 |
| -------------------------------- | ----------------------------------------------------------------- | -------------------------------------------------------------- |
| Reach on the recipient's handset | yes — any numbered handset                                        | partial — only recipients on WhatsApp who opted in             |
| Rich-content shape               | partial — text plus a short link; media lives on the landing page | yes — media, buttons, receipts on the message itself           |
| Delivery + read evidence         | partial — delivered receipts, usually no read receipts            | yes — delivered plus read receipts                             |
| Cost shape                       | partial — per segment; segments grow with long event copy         | partial — per conversation; template category decides the cost |
| Fallback behavior                | yes — chain drops to WhatsApp on rejection, if you wire it        | yes — chain drops to SMS on rejection, if you wire it          |

Read the table as per-stage, not per-platform: the same account runs `order.confirmation` on WhatsApp and `order.delivered` on SMS, with the chain dropping to the other when the first-choice channel refuses the recipient. The checklist exists so that decision is an explicit per-stage call, not an accident of which integration shipped first.

## 4. Evaluation surfaces

Ground the channel choice on the same surfaces you would read a retail-notification result from:

* **Sandbox API key** — send test events against a `dv_test_sk_` sandbox key with simulated sends costing \$0; walk an order-confirmation event end-to-end before committing a stage. Start from the [quickstart](/quickstart).
* **Order notifications ledger** — the [ledger](/guides/order-notifications-ledger) shows per-stage channel mix, delivery rate, and failure breakdown, so you can read which channel actually carried each stage against the intended first-choice channel.
* **Fallback-chains recipe** — the [recipe](/guides/fallback-channels-recipe) shows the exact per-chain wiring that turns "first-choice refused" into "dropped to the other channel" instead of a lost event.
* **Pricing page** — [orbit.devotel.io/pricing](https://orbit.devotel.io/pricing) is the same surface a signed tenant bills against; model your stage mix there rather than trusting a published average.

Use these surfaces for whichever first-choice channel you are testing — the point of the checklist is that you own the verdict, whichever way it lands.

## 5. When not to move — FAQ

**When does SMS-first genuinely win a stage?**
When your recipient list skews to handsets you cannot verify are on WhatsApp — older devices, markets with low WhatsApp penetration, or customers whose consent record is SMS-only — and the event is a plain-text stage like a delivery alert that carries one tracking link. The checklist scores that honestly: reach over rich content, and for many stage types that is the correct trade.

**When does WhatsApp-first genuinely win a stage?**
When the event wants read evidence or rich content — an order confirmation the customer should open, a delivery photo, a signed-for receipt — and your recipient list demonstrably lands on WhatsApp. Run the ledger for a few days against your real mix and let the per-stage channel-mix column answer the question, not a published penetration average.

**Should a stage move channels mid-flow?**
Only after the ledger shows the per-stage gap. First-choice channel choice is a per-stage tenant decision; moving it because "we updated our defaults" without per-stage evidence is churn, not a verdict. The exception stage — delayed, failed attempt, refunded — is the one place the ledger shows the loss early enough to respond.

**Do we need to rewire the pipeline to switch?**
No. The fallback chain stays; you flip the first-choice channel per stage in your tenant configuration and let the chain handle the recipients who refuse it. Re-reading the [fallback-chains recipe](/guides/fallback-channels-recipe) before the flip is the whole rewiring step.

## 6. Hub link back

This page is one entry of the [evaluating alternatives](/alternatives) catalog — return there for the other capability-class checklists scored on the same template.

## Related references

* [Fallback channels recipe](/guides/fallback-channels-recipe)
* [Fallback chains](/guides/fallback-chains)
* [Order notifications ledger](/guides/order-notifications-ledger)
* [Multi-channel notify](/guides/multi-channel-notify)
* [Smart send fallback chains](/guides/smart-send-fallback-chains)
* [Message suppression](/guides/message-suppression)
* [Authentication](/authentication)
* [Pricing](https://orbit.devotel.io/pricing)