Most dunning advice starts at the failure. The more leverageable moment is earlier: a large share of renewal failures are visible days in advance, in data the billing system already holds. Cards expire on a printed date. Cards get replaced and the vault still holds the old PAN. A customer's first payment needed two attempts. None of that requires prediction models. It requires a job that runs before the renewal, reads the obvious signals, and sends the right message while there is still time for the customer to act without urgency or embarrassment.
Think of pre-dunning as three triggers, each with a different message because each asks for a different action.
Expiry approach. The card on file expires before the next renewal date. The message is pure housekeeping: your card ending in 4417 expires this month, update it here so your plan continues uninterrupted. No mention of failure, because nothing has failed. Send it early enough for a replacement card to physically arrive, which means the trigger is not "expires this month" but "expires before the renewal after next," and the send time should clear weekends, because people update payment details at desks, not on hiking trails.
Retry-risk history. The last successful charge took more than one attempt, or succeeded only after a soft decline. That account is statistically likelier to fail at renewal, and the honest pre-dunning move is not an email at all in many cases: it is checking whether an account updater covers the card, and quietly confirming the credential is current. Email is the fallback when the data cannot be fixed silently. Developers building this trigger should log which path each account took, silent fix or message, because the ratio tells you whether your updater coverage or your copy is doing the work.
Card-change silence. The customer updated their card for a different purchase or a different product and your subscription still points at the old one. Cross-referencing vault tokens per customer, where your processor supports it, surfaces these. The message here must be careful: "we noticed a newer card" can read as surveillance if phrased badly. Anchor it in the customer's own action and the benefit to them, continuity, not in your monitoring.
Implementation details decide whether any of this works. The update link must land on a page that knows who the customer is without making them log in from a cold start on a phone; every extra authentication step measurably bleeds completions. The email itself should be transactional in tone and infrastructure, sent from the same domain family as receipts, because a pre-dunning note that lands in promotions has the deliverability of a newsletter and the urgency of neither. And the whole sequence needs a suppression rule: the moment a payment succeeds or a card is updated, every queued pre-dunning message for that account dies. Nothing teaches customers to ignore billing email like warning them about a problem that no longer exists.
Measurement is refreshingly direct. Track the failure rate of the triggered population against a matched group from before the program, or against a small holdout if your volume allows it. Pre-dunning that works shows up as failures that never happen, which is precisely why it gets undervalued: there is no recovery dashboard for a decline that was prevented. Build the prevented-failure estimate into your reporting from day one or the program will lose every budget argument to work whose results are easier to photograph.
For the message copy itself, including subject lines and the timing ladder for each trigger, pre-dunning email templates keyed to the failure you can see coming collects the set in one place. It is the before picture to Swipe Again's recovery work, which handles the failures that arrive anyway: prevention where the data allows it, recovery where it does not, and honest accounting for both.
Top comments (0)