Here's the failure mode nobody designs for: your billing service goes sideways at 2pm, your incident tooling fires an email to the affected accounts, and 40% of those emails land in a Promotions tab or a spam folder or an inbox that user hasn't opened since Tuesday. From your side, the alert "sent." From the user's side, they found out when a support ticket bounced off a broken checkout. The gap between "we notified them" and "they know" is where trust quietly leaks out.
Full disclosure: I work for Ready, which sells SMS (and a power dialer, and 10DLC handling). So I have an obvious bias toward the channel. But this post isn't "text everyone about everything" — that's how you train users to mute you. It's about building a ladder: in-app first, email second, SMS only as the rung you climb to when the message genuinely can't afford to be missed. Most of your alerts should never make it to the top of that ladder. The whole point is knowing which ones do.
Why a single channel always fails the alert that matters most
Every channel has a silent failure mode. The trap is that the failure is invisible to the sender.
- In-app banners only reach users who are logged in. If your alert is "your account is suspended" or "we're down," the user experiencing the problem may be the one who can't log in — or who already gave up and closed the tab. (We wrote a whole piece on why an in-app banner is invisible to a churned user.)
- Email has a delivery lag measured in tens of seconds, plus a real open-rate cliff. Round industry numbers put transactional-email open rates somewhere in the 30–50% range even for engaged users, and worse for the disengaged. An outage alert that takes 90 seconds to arrive and 40% never open is not an alert — it's a log entry.
- SMS reaches almost everyone, fast, but it costs real money per send and it's the fastest way to burn goodwill if you overuse it.
No single channel is reliable enough for the alerts that actually damage the relationship when missed. So you stack them, and you gate each rung on severity.
The three-rung ladder
The core structure is boring on purpose. Boring is what survives an incident.
- Rung 1 — In-app. Every alert starts here. It's free, it's instant, and for a logged-in user it's the least intrusive place to surface something. If the user sees and acts on it, the ladder stops.
- Rung 2 — Email. Fires in parallel or on a short delay. Handles anything the user should know but doesn't need to act on in the next ten minutes. This is your default for the vast majority of notifications.
- Rung 3 — SMS. Fires only for severities where a missed message costs the user (or you) real money or trust, and only after — or alongside — the lower rungs, depending on urgency.
The design decision that matters is the gate between rung 2 and rung 3. Get it wrong in one direction and users miss the alert that mattered. Get it wrong in the other and they mute you before the alert that matters even arrives.
Which alert types earn the SMS rung
Ask one question per alert type: if the user misses this for six hours, does someone lose money or access? If no, it stays on email. If yes, it climbs.
| Alert type | Severity | Top rung it earns | Why |
|---|---|---|---|
| New feature announcement | Low | Nice to know, zero cost if missed | |
| Weekly usage digest | Low | Informational, batched | |
| Password changed | Medium | Security-relevant but rarely time-critical | |
| Failed payment / card declined | High | SMS | Miss it and the account churns — dunning texts recover ~3x more than email |
| Account suspended / locked | High | SMS | User may be unable to log in to see in-app |
| Security: new-device login | High | SMS | Time-sensitive, account-safety |
| Full service outage affecting them | Critical | SMS | The channel of last resort when your own app is the thing that's down |
| Quota / rate limit hit (production) | High | SMS | Breaks the customer's own users; they need to act now |
Notice the pattern: SMS earns its slot when the alert is either about access the user is losing, or about your product failing in a way that breaks theirs. Everything soft, batchable, or purely informational stays down the ladder.
The money side: what the SMS rung actually costs
This is where teams either overspend by texting everything or underspend by texting nothing. Let's put numbers on it.
A tight outage alert — "Ready: we're investigating a service disruption affecting logins. Updates at status.example.com. Reply STOP to opt out." — is about 115 characters, plain GSM-7, so one segment. On Ready's Standard tier that's $0.02 + $0.0045 carrier = $0.0245 per recipient.
Say a P1 outage hits 3,000 active accounts:
- 3,000 × $0.0245 = $73.50 for the whole incident notification.
Compare that to the churn cost of even ten of those accounts silently deciding you're unreliable, and $73.50 is rounding error. That's the case for SMS on critical alerts.
Now the case for gating: if you also texted those 3,000 accounts every feature release (say twice a month) and every usage digest (weekly), you'd be sending ~26 non-critical texts/account/year. 3,000 × 26 × $0.0245 = ~$1,911/year — and worse, you'd have trained every one of those users to ignore your texts, so the $73.50 outage alert lands muted. You'd have spent money to destroy the channel you were saving for emergencies.
Watch the emoji trap too. Add a single 🔴 to your outage text and the whole message drops to a 70-character unicode limit, splitting a 115-char message into two segments — doubling the per-recipient cost for a decorative dot. On critical alerts, keep it plain text.
If you want to model your own volumes, the pricing tiers drop automatically to $0.016/segment once you cross 50,000 segments in a calendar month — no plan to pick, it just applies.
Severity gating without alert fatigue
The gate is a rule, not a vibe. Some things that have worked:
- Assign a numeric severity to every alert type at definition time, not at send time. If it isn't tagged sev-1 or sev-2, it can't reach the SMS rung. This forces the decision to happen once, deliberately, instead of during an incident when everyone's panicking.
- Cap SMS frequency per contact. Even critical alerts benefit from a ceiling — e.g. no more than one status-change text per incident, not one per micro-update. A flapping service shouldn't fire twelve texts. This is the same class of guardrail as stopping a misfired workflow from texting one contact 40 times — set the cap before you need it.
- Let the lower rung resolve the ladder. If the user clicks the in-app banner and acknowledges within N minutes, suppress the SMS. You only pay for the escalation you actually needed.
- Separate transactional from marketing at the campaign level. Your critical-alert traffic should ride a transactional 10DLC campaign, not a marketing one — registering the wrong use case is why delivery silently drops. Alert texts throttled behind a mislabeled marketing campaign defeat the entire ladder.
Consent and compliance for transactional alerts
Transactional and marketing consent are not the same thing, and alert SMS lives on the transactional side — but you still need the plumbing right.
- Capture opt-in at the point it makes sense (account setup, phone verification, an explicit "text me for critical alerts" toggle) and record the attestation. Ready logs opt-in attestation for bulk and API sends, so you have the audit trail if a carrier or a customer asks.
- Honor STOP automatically. Ready's opt-out handling propagates across campaigns, so a user who opts out of one thing isn't accidentally re-messaged elsewhere. For genuinely critical account-safety alerts, be thoughtful about what "STOP" removes — many teams keep a separate security-alert stream users can't casually mute.
- Register the right 10DLC campaign. For the SaaS-specific version of all this, the SaaS 10DLC compliance guide walks through it. Standard registration (~$10/mo brand + ~$20/mo campaign) covers most alert volumes; brand vetting is only worth it if you need higher throughput.
Quiet-hours enforcement is the one place to make a conscious exception: Ready holds sends outside permitted local hours by default, which is right for marketing — but a 3am P1 outage arguably should wake the on-call admin. Configure that deliberately per campaign rather than letting the default decide for you.
The practical takeaway
Build the ladder once, gate it hard, and let most alerts never leave the bottom two rungs. SMS is the channel of last resort, and it works because it's the channel of last resort — the moment you cheapen it with digests and feature blasts, the outage text that costs you $73.50 to send arrives already muted.
Tag severity at definition time. Cap frequency per contact. Ride a transactional 10DLC campaign, not a marketing one. Keep critical texts plain-GSM-7 single-segment. Do those four things and the SMS rung stays sharp for the day you actually need it.
If you want to wire the escalation into whatever you already run, Ready's automations and two-way inbox sit over self-serve 10DLC that most teams get approved same-day, and there are 2,500 free credits to test the ladder before you spend a dollar — start here.