Skip to main content

​
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 so a missed first-choice channel drops to the other, and read the actual per-stage outcome in the 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. 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 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 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. 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.
  • Order notifications ledger — the 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 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 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 before the flip is the whole rewiring step. This page is one entry of the evaluating alternatives catalog — return there for the other capability-class checklists scored on the same template.