An ecommerce order generates more notifiable moments than a delivery does, and most stores notify on the two that matter least. Payment confirmations are read; shipping updates are acted upon; and a message sent after the parcel arrives is a message that damages trust rather than building it.
This guide maps the order lifecycle to the channels that suit each event, covers what a promotional peak does to capacity, and sets out how to keep the transactional and marketing paths separate so that the first is not judged by the standards of the second.
Which order events deserve a notification?
Seven events, and only three are time-critical.
The lifecycle contains more moments than a customer wants to hear about, and the value of each is not proportional to the effort of sending it.
| Event | What the customer needs | Channel and urgency |
|---|---|---|
| Order placed | Confirmation and order reference | Email or SMS, low urgency |
| Payment failed | To complete the purchase | SMS, high urgency |
| Order packed | Expectation of dispatch | Usually none |
| Dispatched | Tracking reference | SMS with link, high value |
| Out for delivery | To be available | SMS, time-critical |
| Delivered | Confirmation and returns window | SMS or email, low urgency |
| Return or refund | Status and timescale | Email with SMS for exceptions |
The two events that justify immediate SMS are payment failure and out-for-delivery, because both require an action within a window. Payment failure is the more valuable of the two: a customer who does not complete the purchase has not yet become a customer, and the window for recovering the order is measured in minutes.
Dispatch and delivery confirmation carry information the customer wants but not within a window, which makes them suitable for whichever channel is cheaper or preferred. Packed and internal milestones should generally not be sent at all, because they occupy the same channel as the messages that matter.
How does a promotional peak change capacity planning?
It multiplies order volume and notifications.
Peak planning has to account for the fact that marketing campaigns add messages on top of the transactional stream.
Three multipliers apply at once. Order volume rises, and each order generates its own notification sequence. Promotional campaigns add their own messages, which are typically sent in bursts rather than spread across the day. And the support consequences of delayed notifications rise, because a customer waiting for a delivery update during a peak period is more likely to contact the retailer than to wait.
The practical planning consequence is to size the transactional path for the peak transactional volume and to treat promotional traffic as a separate load with its own capacity and its own scheduling. Where both share one device, the promotional stream can delay the transactional messages that generate support contacts, which is the opposite of the intended priority.
The published 16-port, 64-slot configuration at $800.00 suits a retailer that needs both a transactional stream and room for promotional traffic, because the extra SIM slots allow the two to be distributed across different numbers rather than competing for the same ones.
Why must transactional and marketing paths be separated?
Because the standards applied to each are different.
A transactional message and a promotional message carry different obligations, and mixing them weakens both.
Transactional messages are sent because of an action the customer took and are expected as part of the purchase. Promotional messages require consent to marketing, and a recipient who never agreed to receive promotions will treat one as an intrusion. Where both arrive from the same number, the consequence is a complaint about the transactional stream as well, and an opt-out that removes the customer from messages they wanted.
Three separations are worth maintaining. Separate sender identities, so the customer can tell which kind of message has arrived. Separate consent records, because the basis for each is different. And separate opt-out handling, so that declining promotions does not suppress order updates.
The obligation to make those distinctions is a matter of market practice rather than of technology, and the guidance published by M3AAWG and the rules described by organisations such as the CTIA are the practical references. Where a message is used to confirm a customer’s identity, the treatment of that channel is described in NIST SP 800-63B, which is worth reading before a verification flow is built on it.
How should the notification stream be integrated?
From the platform event stream, not its database.
Integrations that read order state periodically produce late and duplicate messages.
The workable pattern subscribes to the order events the platform already emits and maps each to a notification decision. That design gives you a deterministic trigger, an event timestamp to measure latency against, and a natural place to apply the duplicate suppression that prevents a retried event from producing a second message.
Three integration details matter. The mapping from event to channel should be configuration rather than code, because the events worth notifying change with the business. The record of what was sent should be stored against the order, so that a customer enquiry can be answered from one place. And the message content should be generated from the event payload rather than from a template that queries the order again, because the second approach reintroduces the timing problem the event stream solves.
Where the store operates across markets, the numbering conventions a recipient sees are standardised through the ITU E.164 numbering plan, while sender registration requirements remain a matter for each market and should be confirmed rather than assumed.
What should be measured in production?
Latency by event, duplicate rate, and opt-out accuracy.
Three figures predict whether the notification stream is helping or harming.
Latency by event should be measured from the platform event to the handset, and reported as a distribution rather than an average, because the slowest decile is what generates support contacts. Duplicate rate should be near zero; where it is not, the event subscription is firing more than once. Opt-out accuracy should confirm that a promotional opt-out suppresses promotions and does not suppress order updates, since a suppressed delivery notification produces a support call.
A fourth measure is worth adding where the store sends promotional traffic: the proportion of recipients who engage with transactional messages compared with promotional ones. A narrowing gap between the two suggests the channels are being conflated in the recipient’s mind, which is the earliest sign that a separation is failing.
What should be tested before a peak period?
Peak volume, payment failure, suppression.
Peak readiness is a rehearsal, not a review.
- Peak transactional volume. Drive the transactional path to the busiest hour the business has experienced, with promotional traffic running alongside.
- Payment-failure latency. Confirm the message that recovers an abandoned purchase is delivered inside the window in which the customer is still engaged.
- Duplicate suppression. Replay an order event and confirm the notification is not sent twice.
- Opt-out isolation. Opt out of promotions and confirm order notifications continue.
- Channel fallback. Confirm the behaviour when one channel is unavailable, so that a failure does not silently drop notifications.
Item four is the one most often skipped and most likely to generate complaints, because a customer who opted out of marketing and then stopped receiving delivery updates will conclude that the first action caused the second.
Where the store operates in more than one market, the sender identity and registration requirements differ, and the numbering that recipients see follows the ITU E.164 numbering plan while the consent framework remains local. Treating those as separate decisions per market is what prevents a configuration that satisfies one country from being reused where it does not apply.
Where the deployment has to satisfy an equipment framework, the ETSI standards catalogue covers the network and equipment side of the same specification work.
Where the store operates a loyalty or account programme, one further distinction is worth drawing: an account notification is a third category alongside transactional and promotional messages, and it carries its own consent basis. Mixing it into either of the other two streams produces the same problem as conflating transactional and promotional traffic, because a recipient who opted out of one will conclude that the opt-out failed when the other arrives.
Keeping the three streams separate in the configuration, and clearly distinguishable to the recipient, is what makes each one’s opt-out meaningful rather than nominal.
Conclusion
Ecommerce notification design is about choosing which events deserve a message and which channel each deserves. Two events justify immediate SMS — payment failure and out-for-delivery — and the rest belong on whichever channel is cheaper or preferred. Peak planning must account for the promotional stream alongside the transactional one, and the two should use separate sender identities, consent records and opt-out handling.
Integration from the platform’s event stream rather than from periodic reads of its database gives you deterministic triggers, measurable latency and a natural place for duplicate suppression. Measuring latency as a distribution rather than an average is what predicts support load, and the published 16-port, 64-slot configuration at $800.00 gives transactional and promotional traffic separate numbers on one device.
Map your events to channels before sizing the hardware. Send your order volume, event list and peak profile to service@telarvo.com, or review the published models on the SMS gateway solution pages.
FAQ
Which ecommerce events should trigger an SMS?
Payment failure and out-for-delivery justify immediate SMS because both require an action inside a window. Dispatch and delivery confirmation carry useful information but no urgency, so either channel works. Internal milestones such as packed should generally not be sent, because they occupy the same channel as the messages that matter and train the recipient to ignore it.
Can transactional and promotional messages share one number?
They can technically, and it is a poor idea. A recipient who never consented to marketing will treat a promotion from the same identity as the order updates as an intrusion, and their opt-out will suppress messages they valued. Separate sender identities, separate consent records and separate opt-out handling keep the two streams independent.
How much SMS capacity does a peak period need?
Size the transactional path for the busiest hour the business has experienced, with promotional traffic treated as a separate load. Peak periods multiply order volume, add promotional bursts, and raise the support cost of any delay. The relevant figure is peak-hour concurrency rather than daily volume, because a queue that is tolerable in a quiet week is not during a sale.
Why do customers complain about duplicate order messages?
Usually because the integration reads order state periodically rather than subscribing to events, so the same state change is observed more than once. Subscribing to the platform’s event stream, deriving a deterministic key from the order and event type, and recording what was sent against the order removes the duplication and makes the incident answerable from one record.