smart retries
Stripe's retry logic.
dunning
Also: dunning management
Dunning is the communication cadence a vendor uses to recover an unpaid invoice. In SaaS, it usually means the email-and-retry sequence that fires when a customer's recurring payment fails — Stripe retries the card, the vendor emails the customer, and the goal is to recover the payment without losing the relationship.
In context.
Porchops splits dunning into two layers: the technical retry layer (Stripe Smart Retries) and the email layer (Lou). Stripe handles the cadence of retry attempts; Lou handles the contextual recovery email after retries finish.
The split matters because dunning emails fail when they read templated. Lou drafts cause-matched emails that reference the customer's tenure, plan, and recent activity — the email layer is the leverage point, not the retry timing.
Concrete instances.
A customer's payment fails on day 1. Stripe retries on day 2 and day 4. Lou drafts a recovery email at day 2 (after the second retry). Founder reviews and sends. Customer updates card on day 3. Recovered.
Generic dunning template: "Your payment has failed. Please update your card." — reads templated, damages relationship.
Lou's dunning draft: "Hey Sarah — your card got declined for an expired-card error on your Pro plan. Here's a 30-second update link..." — reads founder-written, recovers the customer.
Common questions.
How many dunning emails per failure?
Two. First at 24-48 hours after the initial failure (post-second-retry); second at ~7 days. More than two damages the relationship; fewer leaves recovery on the table.
What tone works for dunning emails?
Founder voice, not marketing automation. Specific, short (under 120 words), clear about the next step. Lou learns the founder's voice from sample emails.
What recovery rate should I expect?
35-55% across the failed-payment surface, with significant variation by decline-code bucket. Expired-card cluster around 70%; soft declines around 50%; hard declines around 15%.