Here's the failure mode nobody puts on the retention dashboard: your dunning system fires a beautiful in-app banner about a failed payment, and the user it's meant for hasn't opened your app in 19 days. The banner renders perfectly. It's also, functionally, a message written on the inside of a door nobody's walking through.
Full disclosure: I work for Ready, and we sell SMS. So take the "send a text" recommendation with the appropriate grain of salt. But the logic here is channel-agnostic and predates my job: the entire premise of in-app messaging is that the user comes back. For the specific alerts where the user has already stopped coming back, in-app is the wrong tool, and it's wrong in a way that quietly costs you revenue you already earned.
This post is about drawing that line honestly — which SaaS alerts justify SMS's per-message cost, and which absolutely don't.
The channel-presence problem
Every messaging channel has a precondition. Email assumes an inbox that gets checked. Push assumes the app is installed and notifications aren't muted. In-app assumes a session. Slack/webhook assumes an integration someone still watches.
SMS's precondition is the weakest of all: the user has a phone, and it's on. That's why it's expensive relative to email, and why you shouldn't spray it. But it's also why it's the only channel that survives the exact condition that breaks the others — the user has disengaged from your product.
So the useful question isn't "is SMS effective?" It's "for this specific alert, is the user's presence on my platform reliable?" When the honest answer is no, and the alert is high-stakes, that's your SMS shortlist.
The three categories that clear the bar
Three types of SaaS alert routinely fail the presence test while being high-stakes enough to justify the cost.
1. Billing and dunning
A card declines. Your job is to reach the person before the involuntary churn hardens into intentional churn. But card-decline events correlate with disengagement — people who stopped using the product are exactly the people whose expired card you're now trying to update.
Involuntary churn is a huge chunk of SaaS churn (industry estimates float around 20–40% of total churn, depending on who you ask and how self-serve the motion is). Some meaningful slice of that is just unreached messaging, not a real decision to leave.
An SMS that says "Hey — the card on file for [Product] declined. Update it here: [link]. Reply STOP to opt out." reaches someone whose banner never will.
2. Security and account events
Suspicious login, password reset, MFA change, a data-export request, a permissions escalation on a team account. These are the alerts where "the user was logged in" is definitionally not guaranteed — half the point is that someone who isn't the legitimate user might be logged in instead.
This is also the category where users have the strongest existing mental model for receiving a text. Nobody's annoyed by a security SMS. The consent story is cleaner too, since it's transactional and account-specific rather than promotional.
3. Win-back with a real deadline
Trial-expiry, a grandfathered-plan sunset, a "your data gets purged in 30 days" event. By definition the win-back target has stopped logging in — that's why they're a win-back target. In-app is the one place they'll never see it.
The nuance: win-back SMS only works with a genuine stake and a real deadline. "We miss you!" is spam. "Your export access ends Friday and the file is 14GB" is a service.
The alerts that do NOT justify SMS
I'd be lying if I told you SMS was the answer for most product notifications. It isn't. Overuse trains people to ignore you and, worse, to text STOP — which, because opt-out propagates across every campaign in Ready, means you lose them for the billing alert too. Guard the channel.
Skip SMS for:
- Feature announcements and changelog. In-app or email. Nobody wants "we shipped dark mode" on their phone.
- Engagement nudges for active users. If they logged in today, the in-app banner works fine and costs nothing.
- Digest-style summaries. Weekly reports, usage recaps — email's whole job.
- Anything without a clear action or deadline. If there's no "do this by then," it's not urgent enough to interrupt.
- High-frequency operational noise. Build alerts, comment notifications, @-mentions. These belong in whatever channel the user already lives in.
The test I use: would a reasonable person be glad this interrupted their dinner? If not, it's not an SMS.
The cost math, honestly
SMS costs real money per send, so let's put numbers on it instead of hand-waving.
On Ready's Standard tier that's $0.02/segment + $0.0045 carrier pass-through = $0.0245 all-in. A typical transactional alert — "Your payment failed, update here: [link]" — lands under 160 GSM-7 characters, so one segment.
| Alert type | Volume/mo | Segments each | Monthly SMS cost |
|---|---|---|---|
| Failed-payment dunning | 400 | 1 | ~$9.80 |
| Security / login alerts | 1,200 | 1 | ~$29.40 |
| Trial-expiry win-back | 800 | 1 | ~$19.60 |
| Total | 2,400 | ~$58.80 |
Fifty-nine dollars a month. Now weigh it against the other side of the ledger: if even ten of those 400 dunning texts recover a $99/mo subscription that would've otherwise churned involuntarily, that's ~$990 in saved MRR against $9.80 in send cost. The ROI on billing SMS specifically is rarely close.
Watch two things in the math:
- Segment count. Add an emoji and your 155-character message flips to unicode encoding, dropping the per-segment limit to 70 characters — a one-segment text can silently become three. For transactional alerts, keep them plain-text GSM-7. No emoji.
- Link tracking. If you wrap the URL in a click-tracker, a shared public shortlink domain can hurt deliverability on exactly the carrier-filtered routes you need for critical alerts. If you track, use a branded domain — we get into that tradeoff in the click-tracking post.
Wiring it up without a rebuild
The reason this often doesn't get built is the assumption that it's a project. It isn't, if your alerts already fire as events.
Ready sends over registered 10DLC routes, which is what keeps transactional alerts from getting carrier-filtered. Two integration paths:
- API. Your billing system already emits a
payment_failedwebhook. Point it at Ready's send endpoint with the user's number and a templated body. Same forlogin_suspicious,trial_ending, whatever your event taxonomy calls them. It's an HTTP call in the same handler that already writes the in-app banner — you're adding a channel, not a system. - GoHighLevel. If your lifecycle motion runs through GHL, the native OAuth integration two-way-syncs messages per sub-account, so an automation triggered by a tag or pipeline stage can fire the SMS and land replies back in the same inbox.
A couple of compliance notes that aren't optional:
- Consent. Transactional account alerts sit on firmer footing than marketing, but you still need opt-in on file and an audit trail. Ready records opt-in attestation for API and bulk sends. Keep your transactional and promotional consent separate — mixing them is a real gap, which we cover in the two-way-vs-broadcast consent post.
- Quiet hours. A 2 a.m. security alert is arguably fine; a 2 a.m. win-back is not. Ready enforces quiet hours by recipient area, and you'll want that on for anything non-urgent.
- This reduces risk; it doesn't eliminate it. Compliance is still the sender's responsibility. Don't let a vendor tell you otherwise, us included.
The one-line policy to steal
If you want a single rule your team can apply without a meeting:
Send SMS only when the user's presence on our platform is unreliable AND the alert has a clear action with a real deadline. Everything else stays in-app or email.
That rule alone routes billing, security, and deadline win-back to SMS, and keeps feature news, digests, and engagement nudges off the phone — which is exactly where the line should sit.
Run your own numbers before you build anything. Count your monthly failed-payment events, multiply by ~$0.0245, and compare it to the MRR sitting inside that involuntary-churn bucket. If the recovery math clears — and for dunning it almost always does — the 2,500 free credits are enough to test the billing flow end-to-end without touching a card. You can see the full pricing on the ReadySMS page or sign up here and wire one event first.
Start with dunning. It's the highest-ROI, lowest-consent-risk alert of the three, and it's the one where the in-app banner is most obviously talking to an empty room.