Designing a Notification System: Dividing the Work Between Email, SMS, and Push

Send too few notifications and users miss things that matter; send too many and they mute you outright — and then miss the truly important ones along with everything else. We've seen too many systems treat notifications as an afterthought bolted on feature by feature: every new feature casually fires off an email, and two years later the user's inbox holds dozens of inconsistently formatted notifications with an open rate approaching zero. Notifications deserve to be treated as a serious design problem: what is worth interrupting the user for, through which channel, and how loudly.

Dividing the work: Email, SMS, and push

The three channels commonly used in Taiwan differ hugely in cost and character, and the division of labor should be explicit:

• Email: nearly free, can carry full content, and stays around for reference — but poor immediacy. Many people check once or twice a day, and it may land in spam. Best for: order details, invoices, statements, monthly reports — content that's "for the record, not urgent."
• SMS: roughly NT$1 per message, extremely high open rates, nearly everyone reads them — but expensive, short, and can't carry much. Best for: verification codes, pickup notices, appointment reminders — "short, urgent, important" messages. Precisely because it costs money, SMS is the best discipline tool: every send stings a little, so you won't spam.
• App push / LINE messages: cheap, instant, and a tap leads straight into the system — but users can revoke permission in a second, and once they do, you've lost that channel forever. Best for: real-time status updates and interaction reminders. In Taiwan, a LINE Official Account often plays the push role in practice; see our piece on integrating a LINE Official Account with e-commerce.

A single event can also be layered across channels: a push notification the moment an order ships, plus an email with the details for the record; users who've disabled push fall back to email. Channels are a delivery strategy, not the same sentence pasted everywhere.

Classify first, send second: what earns the right to interrupt

When we design notifications, we sort events into three tiers first. Transactional: directly tied to the user's money, goods, or rights (payment succeeded, order shipped, booking confirmed, password changed) — must send, and immediately. Reminders: ignoring them costs something but isn't fatal (points about to expire, tomorrow's appointment) — can send, but throttle the frequency. Marketing: good for you, not necessarily for the user (promotions, new features) — must be opt-out, and the opt-out has to be easy to find.

The most common disaster is failing to separate the tiers: marketing messages sent through transactional channels. You gain a few clicks short-term; long-term, users learn "this company's notifications can be ignored," and your transactional notices are buried with the rest. Once that trust burns, it's very hard to earn back.

A notification system is a gatekeeper for the user's attention: the more noise you block on their behalf, the more they trust every alert you do send.

Three engineering essentials: don't let the notification system become its own disaster

First, rate limiting and digests. Events spike: one batch import triggers three hundred "low stock" alerts, and you cannot actually send three hundred emails. You need aggregation (same-type events within ten minutes merge into one message) and daily caps. Second, preference settings. Let users choose which notification types go through which channels — and respect it. This isn't just courtesy; marketing messages are legally required to offer unsubscribe anyway. Third, delivery logs and retries. SMS providers fail occasionally, emails bounce — the system must record the outcome of every notification, and critical ones that fail should retry or fall back to another channel. In a "the system says it sent it, the customer says they never got it" dispute, no logs means it's just word against word.

And one we learned the hard way: filter your recipient list, then filter it again. Before any batch send, the code must verify "does this list actually belong to this message," and test environments must be fully isolated from real recipient lists. The cost of one mistaken apology blast far exceeds the cost of one extra layer of guardrails.

Start small, but pour the foundation right

Not every system needs a full notification center on day one. The pragmatic path: get transactional notifications solid first (with delivery logs), build unsubscribe into marketing messages from the start, then add digests and preferences as volume grows. The key is designing "notifications" as a standalone module rather than letting each feature fire its own — the latter always gets rewritten two years in. If your system is at the stage where notifications keep multiplying while their effect keeps shrinking, talk to us — it's usually a good moment to clean up the architecture.