Failed payment dunning sequence

Use when card failures are churning customers who never intended to leave.

failed-payment-dunning-sequence.md

Download .md

You are a billing communications writer. Write a dunning sequence for failed payments.

Product: {{PRODUCT}}
Retry schedule the billing system uses: {{RETRY_SCHEDULE}}
What happens to access, and when: {{ACCESS_CONSEQUENCE_TIMELINE}}
How the customer updates their card: {{UPDATE_PAYMENT_METHOD}}
Support contact: {{SUPPORT_CONTACT}}

Output a table: Email | Timing relative to the failure | Subject | Preheader | Body under 100 words | Call to action | Tone note

Requirements:
- Treat the failure as a card problem, not a customer problem. Common causes are expiry, a replaced card and a bank block.
- Every email states the exact date access changes, and the single link to update payment details.
- The final email states clearly what has happened to the account and how to restore it.
- Do not shame, do not use "action required" in capitals, do not use red-alert language.
- Do not ask for card details in the email or in a reply. Link to the billing page only.
- No em dashes, no apology padding, no closing summary paragraph.

Then flag any point where the copy timing would conflict with the retry schedule above.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{PRODUCT}}
{{RETRY_SCHEDULE}}
{{ACCESS_CONSEQUENCE_TIMELINE}}
{{UPDATE_PAYMENT_METHOD}}
{{SUPPORT_CONTACT}}

Getting a better result

Align the emails to the actual retry schedule. Telling someone to update a card an hour before an automatic retry succeeds causes confusion.
Never collect card details by email or reply. Link to the billing page every time.
Say the exact date access ends. Vague warnings get ignored until the account is already locked.

Questions about this prompt

Why not just use the emails my billing provider sends?

Because those are written for every merchant, so they cannot state your access timeline, your update route or your support contact. Use this when involuntary churn is a visible share of cancellations. The sequence is aligned to your own retry schedule, which the generic version has no way to know.

What do I need from the billing system first?

The retry schedule it actually runs, the timeline for what happens to access and when, the exact route a customer uses to update a card, and a support contact. Take the retry schedule from the billing settings rather than memory, because the final check compares your copy timing against it.

What does the dunning table return?

A row per email with timing relative to the failure, subject, preheader, body under 100 words, call to action and a tone note, then any point where the copy timing conflicts with your retry schedule. Read the conflicts first: they are the difference between helpful and confusing.

What must never appear in a dunning email?

A request for card details, in the email or in a reply. It trains customers to send card numbers by email, which is exactly what a phishing message asks for. Link to the billing page every time, and give the exact date access changes rather than a vague warning.