Dunning Optimization with Mailchimp

What Dunning Optimization Actually Requires

Failed payments are not a customer service problem. They are a revenue operations problem, and the window to recover that revenue is narrow — typically 7 to 14 days before a subscription lapses and a customer churns involuntarily.

Dunning optimization covers two distinct activities: pre-dunning (alerting customers before their card fails, usually when expiration dates are approaching) and retry sequencing (sending the right message at the right time after a payment has already failed). Done well, you can recover 20–40% of failed payment revenue that would otherwise be lost.

Mailchimp can handle the email execution layer of this system. It is not a billing platform. It does not know when payments fail unless you tell it. That distinction matters before you build anything.

---

How Mailchimp Fits Into a Dunning Stack

Mailchimp's role here is as the communication layer, not the trigger layer. Your billing system — Stripe, Recurly, Chargebee, or similar — owns payment data. Mailchimp receives signals from that system and sends the right message at the right time.

The architecture looks like this:

1. Billing system detects a failed charge or upcoming card expiration
2. Billing system pushes data to Mailchimp via API or a connector (Zapier, Make, or native integration)
3. Mailchimp fires a pre-built email sequence based on the event
4. Customer clicks through, updates payment details, charge succeeds

If you do not have an integration between your billing system and Mailchimp, nothing else in this guide works. Set that up first.

---

Setting Up Your Audience and Custom Fields

Before building any automation, your Mailchimp Audience needs to carry the right data.

Custom Fields to Create

In Audience → Manage Contacts → Settings → Audience fields and *|MERGE|* tags, add the following fields:

• CARD_EXP (Date field) — Card expiration date pulled from your billing system
• FAIL_DATE (Date field) — Date of the most recent failed payment
• FAIL_COUNT (Number field) — Number of consecutive failed payment attempts
• PLAN_NAME (Text field) — Subscription tier, useful for personalizing copy
• UPDATE_URL (Text field) — Direct link to your payment update page, ideally pre-authenticated

These merge tags become the backbone of your email personalization. A message that says "Your Visa ending in 4242 failed on March 3" converts better than a generic payment alert. Pull that specificity from your billing system and store it in these fields before the automation fires.

---

Building the Pre-Dunning Sequence in Customer Journeys

Customer Journeys is Mailchimp's automation builder. For pre-dunning, you are targeting subscribers whose card expiration date is approaching — typically 30, 15, and 7 days out.

Journey Setup

1. Go to Automations → Customer Journeys → Create Journey
2. Set the Starting Point to "Date-based" and select the CARD_EXP field
3. Configure the trigger to fire 30 days before that date

Recommended Journey Map

• Day -30: First pre-dunning email. Friendly, low urgency. Subject: "Your payment method expires soon." One clear CTA linking to `*|UPDATE_URL|*`.
• Day -15: Second touchpoint. Slightly more direct. Mention the specific plan and what access they will lose.
• Day -7: Final pre-dunning email. Urgency increases. Frame it around continuity, not failure.

Use Journey Points to add time delays between steps. Each email should be a separate Email step in the journey, not a single send.

---

Building the Post-Failure Retry Sequence

This sequence fires after a payment has already failed. Your billing system should update FAIL_DATE and FAIL_COUNT in Mailchimp each time a retry attempt is made.

Journey Setup

1. Create a new Customer Journey
2. Set the Starting Point to "API trigger" or use a tag-based entry: when the contact receives the tag `payment-failed`, they enter the journey
3. Apply the tag from your billing system via the Mailchimp API or your Zapier/Make integration

Recommended Sequence

• Day 0 (immediately after failure): First recovery email. Keep it factual. Payment failed, here is how to fix it. No blame, no dramatic language.
• Day 2: Follow-up. Remind them their access is at risk. Reinforce the update link.
• Day 5: Third email. If FAIL_COUNT is greater than 1, acknowledge the recurring issue. "We have tried a few times" builds honesty.
• Day 8: Final attempt. Make the stakes clear. After this, access is suspended.

Use Mailchimp's Conditional Content blocks to vary messaging based on `*|FAIL_COUNT|*` — a first-time failure warrants a softer tone than a third consecutive failure.

---

Segmentation and Suppression

Not every subscriber should receive the same dunning path.

• Segment by plan value: Use `*|PLAN_NAME|*` to send different emails to enterprise vs. basic tier subscribers. High-value accounts may warrant a personal outreach note rather than a template.
• Suppress resolved contacts immediately: When a payment succeeds, your billing system must remove the `payment-failed` tag and suppress further emails. Mailchimp's Tag-based suppression handles this when paired with your API integration.
• Exclude recent churns: Contacts who have fully cancelled (not failed, but voluntarily churned) should not receive dunning sequences. Use a separate Segment to filter them out of journey entry.

---

Limitations of Mailchimp for Dunning

Mailchimp is a solid execution layer, but it has real constraints for this use case.

• No native billing integrations. Mailchimp does not connect directly to Stripe, Chargebee, or Recurly out of the box. Every trigger requires a third-party connector or custom API work.
• Limited real-time triggering. Customer Journeys can feel sluggish on lower-tier plans. If your billing system fires a webhook at 2am, the email may not send until morning. For high-velocity retry sequences, this lag matters.
• No native revenue reporting. Mailchimp cannot tell you how much revenue your dunning sequence recovered. You need your billing system or a BI tool to close that loop.
• Conditional branching is basic. If you want to branch a journey based on whether someone opened email 2 before sending email 3, the Customer Journeys builder supports this — but complex logic with multiple conditions gets unwieldy fast.

If your subscription volume is above a few thousand active subscribers and your retry logic needs to be highly responsive, consider pairing Mailchimp with a more specialized retention tool, or evaluate platforms with native billing integrations.

---

Frequently Asked Questions

Can Mailchimp trigger emails automatically when a payment fails?

Not natively. Mailchimp does not have a built-in connection to payment processors. You need to push data from your billing system to Mailchimp using the API or a tool like Zapier or Make. Once that data arrives — typically as a tag or a field update — a Customer Journey can fire automatically. The automation itself works well; the integration layer is what requires setup work.

How do I prevent dunning emails from going to customers who already fixed their payment?

Use tag-based suppression. When a payment succeeds, your billing system should call the Mailchimp API to remove the `payment-failed` tag. In your Customer Journey, add a conditional check at each step: if the tag is no longer present, exit the contact from the journey. This prevents someone who resolved their issue on day 1 from receiving the urgent day-8 email.

What send times perform best for dunning emails?

Tuesday through Thursday, between 9am and 11am in the recipient's local time zone, consistently outperform other windows for transactional and account-related emails. Mailchimp's Send Time Optimization feature can help if you have enough historical engagement data, but for dunning sequences, a fixed morning send on a weekday is a reliable default. Do not send dunning emails on Friday afternoon or over weekends — response rates drop significantly.

Is Mailchimp the right tool if I have a high volume of failed payments?

It depends on your definition of high volume. Mailchimp handles the email sending at scale without issues. The constraint is on the integration and logic side. If you are processing thousands of failed payments per month with complex retry logic, varying grace periods by plan type, and need real-time responsiveness, Mailchimp's journey builder will start showing limitations. In that case, look at platforms like Klaviyo or Braze that offer more sophisticated conditional branching and tighter webhook responsiveness.