Here's a failure mode I've watched happen at more than one SaaS company: the payment fails, the system fires a beautiful in-app banner — red bar across the top, "Update your card to avoid interruption" — and it renders perfectly for a user who will never see it, because the reason their card failed is the same reason they stopped logging in three weeks ago.
The banner isn't the alert. The banner is a note you left on the desk of someone who moved out.
Full disclosure: I work for ReadySMS, so I sell SMS. That means I'm the wrong person to tell you to text everything — a text costs real money and every over-notified user is a STOP waiting to happen. This post is mostly about the opposite: figuring out the narrow set of alerts where in-app and email genuinely can't reach the person, and where paying for a segment is the only thing that works.
The channel assumption that quietly breaks
Most SaaS notification systems are built on an assumption nobody wrote down: the user will come back to the product. In-app messaging, feature-tour tooltips, dashboard banners, the little red dot on the bell icon — all of it depends on a session that may never happen.
For engaged users, fine. In-app is free, it's contextual, and it shows up exactly where the action needs to happen. For a healthy active account, don't text — you'll annoy them and burn opt-in goodwill.
The problem is that your most business-critical alerts cluster around the exact users who've stopped showing up. The failed payment. The security event on a dormant account. The win-back for someone who churned. These are the moments where the message matters most and the user's presence in-app is least likely.
Email is the usual fallback, and it's a reasonable one — cheaper than SMS, no per-segment cost, higher character budget. But email to a lapsed user competes with an inbox they've also stopped reading, and dunning email in particular gets filtered, promo-tabbed, and ignored. We've written up the actual recovery-rate gap in Failed-Payment SMS Recovers 3x More Than Email Dunning. The short version: SMS gets opened, usually within minutes, which is exactly the property you need when the account is on a clock.
The three alert types that justify SMS
Not every notification earns a segment. These three do, because in every case the value of reaching the person exceeds the cost by orders of magnitude, and no other channel reliably reaches them.
1. Billing failures (dunning)
A failed payment is a countdown. Card declines, retries fail, and on some fixed day the account suspends and the revenue is gone. The user causing the problem isn't in the app — an expired card doesn't announce itself with a login.
Do the math on whether it's worth it. Say your ARPU is $49/month and you're recovering annual plans worth $588. A dunning text is one or two segments — call it 2 segments at $0.02 plus $0.0045 carrier on the ReadySMS Standard tier, so about $0.049 per contact. If you send to 1,000 failed-payment accounts, that's roughly $49 total. Recovering even three annual subs pays for the entire campaign 30 times over. This is the clearest positive-ROI text in all of SaaS.
The catch is timing — there's a window where the text works and a window where it just annoys someone who already fixed it. The dunning post above maps that window; I won't repeat it here.
2. Security and account-integrity events
New login from an unrecognized device. Password changed. API key rotated. MFA disabled. Payout account edited on a fintech product.
These are the events where a delayed notification isn't just a missed upsell — it's a potential account takeover. An in-app banner is useless if the attacker is the one logged in and the real user is nowhere near the product. Email helps, but if the attacker also has inbox access, email is compromised too. SMS to a number on file is often the only out-of-band channel left.
Note: high-value security codes and login OTPs are often better handled by dedicated verification providers with sub-second SLAs. What SMS is great for here is the human-readable heads-up — "We noticed a new login to your account from Portland. Wasn't you? Reply HELP." — sent alongside or after the fact.
3. Win-back for genuinely lapsed users
The user hasn't logged in for 30, 60, 90 days. By definition, in-app messaging cannot reach them — that's what "lapsed" means. Email is the default, but for the deeply dormant, email open rates collapse.
This is where SMS earns its cost precisely because it doesn't depend on the product. We cover the mechanics in Reducing Churn in SaaS with Targeted SMS Campaigns, and the freemium version of the same problem — free users who never log back in — in In-App Upgrade Prompts Miss the 70% of Free Users Who Never Log Back In.
Which alerts do NOT justify SMS
Just as important, because over-texting is how you train users to hit STOP and lose the channel for the alerts that matter.
| Alert | Best channel | Why not SMS |
|---|---|---|
| Feature announcement | In-app / email | User is active; no urgency; low value-per-message |
| Weekly usage digest | Long-form, non-urgent, scannable inbox content | |
| Onboarding step nudge (active trial) | In-app / email | User is in the product; in-app is contextual and free |
| Comment/mention notifications | In-app / push | High frequency; SMS would be spammy fast |
| Upsell to an active power user | In-app | They're logged in — reach them where the action is |
| Newsletter / content | No time pressure, no per-segment justification |
The pattern: SMS earns its cost when the message is urgent, high-value, and going to someone who isn't in the product. Miss any of those three and a cheaper channel wins. If you're texting an active user an upgrade prompt, you're often reducing conversion — we broke that down in When NOT to Send a SaaS Upgrade Text.
Wiring it up: automations and API, not manual blasts
None of this works as a manual export-and-blast. Billing failures fire from Stripe webhooks. Security events fire from your auth layer. Win-back fires from an inactivity threshold in your product analytics. Each needs to trigger a text automatically, at the moment the event happens.
That's an API integration, not a campaign UI. ReadySMS sends a segment via a single API call, so your dunning worker or your security-event handler can trigger the text inline. For teams running GoHighLevel as the CRM/lifecycle layer, the native GHL integration two-way-syncs inbound and outbound so a "reply HELP" lands somewhere a human sees it.
A few implementation notes that save pain later:
- Register the right campaign type. A billing or security alert is transactional, not marketing. Registering it as a marketing campaign is a common way delivery silently degrades — see Registering a 'Marketing' Campaign for Transactional Texts.
- Quiet hours still apply. ReadySMS holds sends outside permitted local hours by default. A 3 a.m. security text is legally riskier and practically ignored; the hold is a feature, not a bug.
- STOP is honored automatically and propagates. If a user opts out of your win-back texts, that opt-out carries across campaigns — which is exactly why you don't want to have burned them with newsletter spam first.
A quick worked example
Say you run a $79/month B2B tool with 4,000 active accounts and a 4% monthly involuntary-churn rate from failed payments — 160 accounts a month hitting dunning. You send each a 2-segment recovery text with a link.
- 160 accounts × 2 segments × ($0.02 + $0.0045) = ~$7.84/month in send cost.
- If SMS recovers even 25% of those 160 accounts that email alone would have lost — 40 accounts × $79 = $3,160/month in retained MRR.
You don't need the recovery rate to be impressive. You need it to clear $7.84. Run your own numbers on the cost calculator with your ARPU and volume — the ROI on critical off-platform alerts is rarely close.
The practical takeaway
In-app messaging is the right default for engaged users and free for the messages that matter to them. It breaks completely the moment the user stops logging in — and your most consequential alerts (billing, security, win-back) are aimed squarely at users who've done exactly that.
So the channel decision isn't "SMS vs in-app" in the abstract. It's: is this message urgent, high-value, and going to someone who isn't in the product? If yes on all three, SMS is often the only thing that lands. If not, use the cheaper channel and save the opt-in.
If you want to test it on your own dunning or win-back flow, ReadySMS starts with 2,500 free credits and no card, and 10DLC registration for a transactional campaign usually clears in a day or so. Wire one webhook to one text, measure the recovery, and let the math decide the rest.