Involuntary churn is the dumbest churn you have. The customer didn't leave. They still want your product. Their card expired, hit a daily limit, or got reissued after a fraud alert, and your dunning email is sitting unread under 40 other unread emails. For most SaaS billing stacks, failed payments account for somewhere around 20–40% of total churn — and a meaningful slice of it is purely a communication problem, not a value problem.
Full disclosure: I work for ReadySMS, so I have a horse in the "you should add SMS to this" race. I'm going to show you the actual math anyway, including the cases where SMS barely moves the needle, because the timing matters more than the channel.
Why email dunning leaks so badly
The standard dunning flow is three to five emails over two weeks: "Your payment failed," then a couple of nudges, then a "we're suspending your account." It works well enough that nobody questions it. But two things quietly kill it:
- Open rates. Transactional billing emails open at maybe 30–45%. That's the optimistic version. A lot of them route to Promotions or Updates tabs and never get seen.
- Latency. Even when the email gets opened, it's often hours or a day later. By then your payment processor has already auto-retried — and failed again — burning a retry attempt on a card the customer hasn't fixed yet.
SMS doesn't have either problem. Texts get read, and they get read fast — most within a few minutes. Industry chatter puts SMS open rates north of 90%, and dunning specifically tends to see recovery lifts in the 2–3x range over email-only when the text lands before the retry. The "before the retry" clause is the whole ballgame.
The window that actually matters
Here's the part most teams get wrong. They add SMS as a parallel channel — fire an email and a text at the same time, both saying "payment failed." That's fine, but it leaves money on the table.
The leverage is in the gap between the first decline and the automatic retry. Stripe (and most processors using Smart Retries) will re-attempt a failed card on a schedule — often 3 to 7 days out. If you can get the customer to update their card before that retry fires, you turn a wasted retry into a successful charge instead of a second decline that pushes the account closer to suspension.
So the timing you want looks like this:
- Hour 0: Card declines. Send the SMS immediately (subject to quiet hours — more on that below).
- Hour 0–48: Customer taps the update link, fixes the card.
- Day 3–7: Processor's scheduled retry now succeeds because the card is already good.
The text isn't replacing the retry. It's priming it. That's the difference between a 3x lift and a "meh, SMS did about the same as email."
The cost math (this is where it gets stupidly cheap)
Let's price a real dunning text. A clean failed-payment message:
"Hi Sam — your payment for Acme Pro didn't go through. Update your card here so you don't lose access: acme.co/billing — Reply STOP to opt out."
That's around 140 characters with the STOP footer, so it fits in one 160-character GSM-7 segment. No emoji, no unicode — keep dunning texts plain so they don't balloon into 70-character unicode segments.
On ReadySMS Starter pricing, one segment is $0.0155 plus the $0.0045 carrier pass-through = $0.02 per text. A flat two cents.
Now the recovery model. Say you have 1,000 failed payments a month on a $49/mo plan:
| Step | Number |
|---|---|
| Failed payments/month | 1,000 |
| Texts sent (assume 2 per dunning cycle) | 2,000 |
| SMS cost @ $0.02/segment | $40.00 |
| Incremental recoveries vs. email-only (conservative 8% of failures) | 80 accounts |
| Saved MRR (80 × $49) | $3,920 |
| First-month ROI | ~98x |
That 8% is deliberately conservative — it's the additional accounts you recover beyond what email-only would've gotten. And $49/mo MRR isn't a one-time win; if those 80 accounts stick around even six months, you've protected ~$23,500 in revenue for $40 of sends.
I'm not going to pretend every SaaS sees 8% incremental recovery. If your email dunning is already excellent and your customer base is corporate (people who don't read texts at work), it might be 2–3%. Even at 2% — 20 recoveries, $980 saved — you're at roughly 24x. The send cost is so low it's almost impossible to make this math lose. The variable is your recovery rate, not your spend.
If you want to plug in your own numbers, the cost calculator and the SaaS-flavored ROI walkthrough will get you there.
Quiet hours, or how not to text someone at 3 a.m. about their card
Speed is the point — but "send immediately" has a sharp edge. A card declines at 11:40 p.m. the customer's time. Firing a billing text at midnight is a great way to wake someone up annoyed and earn a STOP.
ReadySMS enforces quiet hours based on the recipient's area, so a send queued at 11:40 p.m. holds until permitted local morning hours instead of going out immediately. You lose a few hours of latency, but you keep the message in a window where it's read favorably and where you're not creating TCPA exposure by texting outside permitted times. For dunning, that tradeoff is correct — an extra eight hours of delay costs you nothing if the processor retry is still days out.
This is the part automation makes invisible: you set the rule once, and every queued failed-payment text respects it without you babysitting send times.
The consent question nobody wants to think about
Here's where SaaS teams freeze up. "Can I even text someone about their failed payment? They never opted into SMS."
The short version: dunning texts are transactional — they relate to an existing account and a service the customer is actively paying for, not a marketing message. Transactional billing notifications sit on much firmer ground than promotional blasts. But "firmer ground" is not "do whatever you want," and a few things still matter:
- Capture the phone number with a clear purpose. If your signup or billing settings collect a mobile number for account/billing notifications, say so in the UI. ReadySMS records opt-in attestation so you have an audit trail of consent basis.
- Honor STOP regardless. Even transactional texts need a clean opt-out path. ReadySMS handles inbound STOP automatically and propagates the opt-out so the contact can't be messaged again — including across other campaigns.
- Don't bolt marketing onto a billing text. The moment your "update your card" message includes "and check out our new Pro tier!", you've arguably turned a transactional message into a promotional one, and the consent rules tighten. Keep dunning dunning.
- Register your 10DLC campaign honestly. This is account-notification traffic. Register it as such. (If 10DLC is new to you, the SaaS 10DLC explainer covers the brand + campaign setup.)
I'm not your lawyer, and compliance is ultimately the sender's responsibility. But the framing — existing customer, existing service, account-related notification, clean opt-out — is about as defensible as SMS gets.
How to actually wire it up
You don't need a custom integration to do this. The mechanics:
- Trigger on the failed-payment webhook from Stripe/your processor (
invoice.payment_failedor equivalent). - Fire the SMS via API or, if you run on GoHighLevel, through a workflow connected to ReadySMS — the two-way sync means replies land back in your inbox.
- Send a second text 48–72 hours later only if the payment is still failing. Suppress it the moment the card updates, so you're not texting people who already fixed it.
- Stop on success or on the processor's final retry. No "your account is suspended" text unless you genuinely suspended it.
That third step — suppressing on resolution — is where teams accidentally double-text people who've already paid. If you're on GHL specifically, it's worth reading the workflow mistakes that double-text contacts before you ship this, because a failed dunning trigger that doesn't check current payment status is exactly the kind of thing that fires twice.
The takeaway
Failed-payment SMS isn't a clever growth hack. It's plumbing — cheap, boring, high-leverage plumbing. The cost is rounding-error small ($40 to text 1,000 failed payments twice), the consent basis is sound because it's transactional, and the only real skill is timing the text to land before the processor's retry so you convert a wasted retry into a successful charge.
If you already run dunning email, adding the SMS leg is a couple hours of webhook wiring and a quiet-hours rule. Start with 20 free test sends (pay-as-you-go, no monthly platform fee), wire one trigger, and watch what your involuntary-churn number does over a single billing cycle. If it doesn't move, you've spent a few dollars finding that out — and if it moves like it does for most SaaS, you've protected a few thousand in MRR for the price of lunch.