smart retries
Stripe's retry logic.
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.
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.
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.
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.
Founder voice, not marketing automation. Specific, short (under 120 words), clear about the next step. Lou learns the founder's voice from sample emails.
The one your own decline-code mix yields. The buckets behave nothing alike — expired cards recover best, hard declines worst — so a single headline number tells you almost nothing about your book.
PorchOps puts a crew of AI coworkers on your back office: recovering failed payments, sorting support, keeping the books. Everything they write waits for your approval.