Dunning program
Mara doesn't run this program yet. The plumbing's in place. The program itself ships in the next release. Here's how it will work.
What dunning is
Dunning is the program for failed payments. A subscription renewal hits the card and the card declines. Most products either lose the customer immediately or send a generic "we couldn't charge your card" email that reads like it was written by a billing system, because it was.
Mara's dunning will read like the rest of her work. A specific email from your product to a specific customer who liked it enough to subscribe.
When it will fire
Stripe or Polar will fire an invoice.payment_failed event into Mara's queue. The billing-webhook plumbing for that is already live: your tenant settings page accepts the signing secret, and the webhook URL is in place. The Conductor knows the event type. It just routes to skip right now because the dunning journey archetype isn't written yet.
When it ships, the same event will route into a four-step dunning program over 7 to 14 days.
What will be in it
Four sends, escalating gently.
Send 1 goes out within the hour. "Your card was declined; here's the direct link to update." No alarm bells. Cards expire; this happens.
Send 2 is a friendlier nudge two or three days later. Mara names the specific access at risk. Not "your account," but the actual product surface they used last week.
Send 3 is a heads-up about a soft pause. "We'll keep things running for X more days, then we'll need to pause your access." Honest. No threats.
Send 4 is the final notice the day before the pause. After this, Mara waits. If they update the card later, the Conductor picks up the recovery event and Mara writes a "you're back" email.
How she'll write it
The same way she writes the other programs. The Brand Analyst supplies the voice. The Copywriter writes the specific email. The recipient context for dunning is high: Mara knows what the customer was using, how long they've been a customer, whether they've had prior billing failures.
The tone shifts across the sequence. Email 1 is operational. Email 4 is almost apologetic. The customer's not the problem; the card is.
What you'll control
The same things you control on other programs. Plus a few specific to dunning:
- The retry cadence. Default is 7 to 14 days; some products want shorter, some longer.
- The soft-pause timing. When access actually stops.
- Whether to attach a recovery offer (a free month if they update the card within 24 hours, for example).
Related programs
Dunning overlaps with churn-save but they fire on different signals. Churn-save is for active cancellation. Dunning is for failed payments. A customer can move from dunning into churn-save if they cancel rather than fix the card.
See it ship
The plumbing's in place. The program writes up next. Watch the changelog or read the roadmap.