Dunning Playbooks
The first 50 failed payments: a recovery-setup playbook
You don't need a perfect recovery system on day one. You need your first 50 failed payments to teach you one — here's what to set up and what to check.
You do not need a perfect recovery system on day one. You need your first 50 failed payments to teach you one. The instinct is to over-build — every rail, every edge case, a fourteen-day sequence — before a single failure has come through. Resist it.
The first 50 are a calibration set, not a problem to survive.
Set up the minimum that can learn
The minimum viable recovery setup does four things: capture every failure event in full (store the raw payload), classify the cause, route it to a channel, and record the outcome. That is enough to start learning. Everything fancier — personalised copy, elaborate branching — should wait until the data tells you it is worth it.
Your first 50 failures aren't a problem to survive. They're the dataset that builds your recovery.
After the first 50
| Check | Target / action |
|---|---|
| Classification accuracy | If more than 20% land in "unknown", refine the rules |
| WhatsApp number quality rating | Must be HIGH — if it slips, investigate spam reports immediately |
These two checks catch the failures that quietly poison everything downstream: a classifier that cannot tell failures apart, and a sending number that is sliding toward being blocked.
After 100 failures, and after 30 full sequences
| Milestone | What to check |
|---|---|
| After 100 failures | WhatsApp Utility open rate above 70%; first email open above 40% |
| After 30 complete sequences | Overall recovery rate tracking toward 30%+ in month one, toward 50% by month six |
| If recovery is below 25% | The bottleneck is usually message content or recovery-page friction, not timing |
These numbers are defaults, not laws. They are starting points drawn from comparable subscription businesses — your own production data supersedes every one of them the moment you have enough of it.
What the data will tell you to fix
Once the first 50 to 100 are in, the data points at the real lever — whether to improve mandate setup, add a pre-debit nudge, change the channel mix, collect payment methods earlier, or revisit pricing above the ₹15,000 line. It also tells you whether your later messages even earn their cost: if more than 90% of recoveries happen by the fourth message, the fifth and sixth may not be worth sending.
Where SubsShield fits
SubsShield gives you the classified failures, the channel performance, and the saved-versus-recovered split from the very first message — so your first 50 actually teach you something instead of just passing by. It diagnoses and communicates; it does not move money.
So after your next 50 failed payments, will you be able to say which failure type and which message recovered the most — or only that "some came back"?

