How to Build a Notification Center: Deliverability, Cost and Opt-Out Compliance Across Email, SMS, Push and LINE

That order confirmation nobody received did not cost you half a cent

A supplements retailer, roughly 2,800 orders a month. They sent order confirmations, the system logged "sent," and nobody looked again. Three months later a support ticket review turned up 214 tickets reading "I never got a confirmation — did my order go through?" At six minutes each, that is 21 staff hours a quarter, and it excludes everyone who skipped the call and filed a refund instead. The cause: the sending domain had no DKIM record, so Gmail routed the batch to Promotions and spam. One email costs a fraction of a cent. One support call costs about NT$60. This article is about getting that line right.

When to build one, and when not to

Build a notification center when

• Your system emits time-sensitive messages: order status, appointment reminders, expiry notices, approval outcomes.
• One event needs multiple channels with a fallback (email unopened, so send an SMS).
• You need an audit trail of who was notified, when, with what, and whether it arrived — common in finance, healthcare and education.
• Monthly volume exceeds roughly 3,000 messages, past the point where resending by hand is viable.

Do not build one yet when

• You send under 500 messages a month on a single channel. An off-the-shelf newsletter tool or manual sends from the admin panel is enough.
• What you actually need is marketing broadcast, not system notification. The technical requirements, legal requirements and sender reputation profiles differ; forcing them together breaks both.
• Nobody in the company owns the bounce report. A notification system with no owner becomes a black box nobody trusts within three months.
• The only goal is cutting SMS spend. If the target is cost rather than deliverability, fix routing rules first, not the system.

Alternatives matrix

For most Taiwanese SMBs the right answer is hybrid: a thin self-built notification layer sitting on top of an email SaaS and a local SMS provider, with LINE as a value-added channel. The value is not in sending. It is in "send once per event, retry through another channel on failure, and log every attempt."

Full process breakdown

• Week 1 — Notification inventory: list every message the system can emit, with columns for event, recipient, channel, urgency, and failure tolerance. Deliverable: a notification matrix (Google Sheet or Notion). Skip this and everything downstream is guesswork.
• Week 2 — Sender reputation and domain setup: configure SPF, DKIM and DMARC, and stand up a dedicated transactional subdomain (e.g. mail.example.com) separate from marketing. Deliverable: DNS records plus a passing check against Google's sender guidelines.
• Weeks 3–4 — Notification core: build the event → template → channel → queue skeleton, with idempotency keys so retries cannot duplicate sends. Tooling: Laravel Notification, Redis queues, Horizon for monitoring. Deliverable: an admin page that can fire test notifications.
• Week 5 — Channel integration: email (Amazon SES or Postmark), SMS (a local Taiwanese provider), app push (FCM / APNs), LINE Messaging API. Deliverable: one confirmed delivery log per channel.
• Week 6 — Preference center and unsubscribe: let users choose by category — transactional cannot be disabled, marketing can, reminders are channel-selectable. Deliverable: a front-end preference page plus unsubscribe links.
• Weeks 7–8 — Monitoring and degradation: deliverability dashboard, retry strategy, and a daily spend cap that suspends marketing while preserving transactional traffic. Tooling: Grafana or an in-house report plus UptimeRobot. Deliverable: a one-page dashboard and an alerting rules document.

Full cost breakdown

• Development: email-only from NT$120,000; four-channel with preference center and dashboard from NT$280,000.
• Email delivery: Amazon SES at roughly US$0.10 per thousand messages; a service like Postmark with full event tracking runs about US$15 per 10,000. At 30,000 messages a month, roughly NT$100–1,500.
• SMS: Taiwanese providers run roughly NT$0.7–1.0 per message at volume, NT$1.2–1.5 for small volumes. At 3,000 messages a month, NT$2,100–4,500. This is the most expensive channel and the easiest to lose control of.
• App push: FCM and APNs are free; the cost is app-side development and token maintenance, roughly NT$40,000–80,000 one-off.
• LINE Official Account: plans include a free message allowance with paid top-ups beyond it; check the official pricing page for current figures.
• Hidden costs: DNS management for the dedicated sending subdomain, about two hours a month cleaning suppression lists, minimum prepaid balances with SMS providers, and the item everyone forgets in year one — template revisions, at roughly NT$1,500–3,000 in design and copy per new notification type.

Reality vs client expectation

• Clients assume connecting the API means messages arrive. Reality: sent, delivered and opened are three different numbers with up to 30 points between them. A new domain without DKIM lands in spam for the first month as a matter of course.
• Clients assume SMS is the reliable channel, so everything important goes by SMS. Reality: deliverability is high, but it costs two to three hundred times email and carries no rich content. Reliable means email as the base with SMS as fallback for critical events.
• Clients assume everyone uses LINE, so send everything there. Reality: only people who added the official account receive anything, typically 30–60% of your member base, and push messages are metered.
• Clients assume unsubscribe means one "cancel subscription" link. Reality: unsubscribe has to be categorized. A single master switch means users disable order notifications to stop ads, then call to ask where their order is.

Common traps and how to avoid them

• Trap: transactional and marketing share a sending domain. One heavily-reported campaign takes order confirmations down with it. → Fix: two subdomains and two API keys from day one.
• Trap: no idempotency key. A queue retry sends five confirmations for one order. → Fix: a unique key built from event ID + user ID + channel, checked before write.
• Trap: no SMS spend cap. One loop bug can burn six figures in half an hour. → Fix: hourly and daily volume and spend ceilings at the notification layer, auto-downgrading to email and alerting on breach.
• Trap: push tokens are never cleaned. Users change phones or delete the app; the token dies but the deliverability report still uses the total as its denominator. → Fix: mark on failure feedback and purge monthly.
• Trap: nobody reads the bounce report. Hard bounces accumulate and drag down domain reputation. → Fix: alert when bounce rate exceeds 2%, and name an owner.
• Trap: critical notices on a single channel. A user changes email or unfriends the LINE account and stops receiving anything, permanently. → Fix: three layers for critical events — primary channel, fallback channel, in-app inbox.

Success metrics and the first 90 days

• Day 30: all transactional notifications live. Watch two numbers — delivery rate (target ≥98%) and hard bounce rate (target ≤1%). Record the current share of support tickets about missing notifications as a baseline.
• Day 60: preference center and categorized unsubscribe live. Look at the composition of unsubscribes — if "all" exceeds 70%, your categories are too coarse. Start comparing real open rates per channel and reallocate budget.
• Day 90: degradation and spend caps in place. Watch unit cost (average cost per effective notification) and the drop in missing-notification tickets. Most projects can cut SMS volume by 30–50% at this point with no impact on experience.

Decision checklist

• ☐ We send more than 3,000 system notifications a month.
• ☐ We use more than one channel (email / SMS / push / LINE).
• ☐ Customers have complained about not receiving notifications.
• ☐ I can state last month's delivery rate.
• ☐ Our sending domain has SPF, DKIM and DMARC configured.
• ☐ Transactional and marketing use different sending domains.
• ☐ Retries cannot produce duplicate notifications.
• ☐ Users can disable marketing while keeping transactional messages.
• ☐ SMS has a daily volume or spend cap.
• ☐ Someone reviews bounce and failure reports on a schedule.
• ☐ Critical notifications have a fallback channel.
• ☐ I can look up whether a notification was sent for an order three months ago.
• ☐ Marketing SMS offers a working opt-out.

Fewer than 8 checks and this line is quietly leaking customers.

FAQ

Can a LINE Official Account replace email notifications?

Not as the only channel. LINE has the highest open rates in Taiwan, but only friends of the account receive messages — typically 30–60% of your member base — and messages with legal weight (contract changes, personal data notices) are weaker evidentially when sent solely through a messaging app. The sound configuration is email as the base layer with LINE as an open-rate booster.

How do I bring SMS costs down?

Three moves in order. First, remove non-urgent messages from SMS entirely (marketing, monthly summaries). Second, switch to "email first, SMS only if unopened after X hours." Third, negotiate volume pricing with a local provider. Most clients cut 30–50% of volume with the first two alone.

What regulations apply to a notification system in Taiwan?

Marketing messages fall under the Personal Data Protection Act: collection requires a specified purpose and notice, and you must provide a way to stop use (opt out). Transactional notices are necessary to perform the contract and sit in a different category. In practice, separate the two technically, and state clearly in the preference center which categories cannot be disabled and why.

We already use a newsletter tool. Do we still need this?

If all you send is marketing email, no. As soon as you have system-triggered messages that need an audit trail — order created, appointment tomorrow — a newsletter tool stops fitting. It is designed around "one list, one email." A notification center is designed around "one event, one person, traceable."

Next step

ScriptWalker's notification center build starts at NT$120,000 for email-only and NT$280,000 for the four-channel version with preference center and deliverability dashboard, over roughly 6–8 weeks. If you just want to know where you are leaking today, we will run a notification inventory free: every message your system can emit, its current channel and delivery status, delivered as a notification matrix.

• Email: [email protected]
• Phone: 0916-224-047
• LINE: @ufv9089p