Dunning Optimization with Intercom

What Dunning Optimization Actually Requires

Failed payments are silent killers. A card expires, a bank flags a transaction, and a paying customer becomes churned — not because they wanted to leave, but because no one caught it in time. Dunning optimization is the systematic process of recovering those payments before the relationship breaks.

Most teams treat dunning as an email problem. Send a sequence, hope someone clicks, move on. The teams recovering 60-80% of failed payments treat it as a messaging orchestration problem — one that requires hitting users at the right moment, in the right context, with a clear path to fix the issue.

Intercom is not a billing tool. It does not retry charges, manage payment processors, or generate dunning logic natively. But it is exceptional at one thing: reaching users inside your product at moments of high intent. That gap — between a failed payment event in your billing system and a user who needs to act — is exactly where Intercom earns its place in a dunning stack.

---

How Intercom Fits Into a Dunning Stack

Your billing system (Stripe, Chargebee, Recurly, Paddle) owns the retry logic and payment state. Intercom's job is to surface that state to the user and drive action before the account lapses.

The three layers where Intercom contributes:

• Pre-dunning alerts: Warn users before a card expires or a payment fails
• In-app recovery messaging: Reach users inside the product when email alone isn't enough
• Guided resolution flows: Walk users through updating payment details step by step

---

Step-by-Step Implementation

Step 1: Connect Your Billing Data to Intercom

Intercom's Custom Attributes on user or company records are how you surface payment state. Before building any messaging, you need the right data flowing in.

Push these attributes from your billing system to Intercom via the REST API or a data sync tool like Segment:

• `payment_status` — values like `active`, `past_due`, `failed`, `cancelled`
• `card_expiry_month` and `card_expiry_year`
• `next_billing_date`
• `failed_payment_count`
• `last_failed_payment_date`

Once these attributes exist on user records, every Intercom feature — Messages, Series, Checklists, and Product Tours — can use them as targeting conditions.

Step 2: Build Pre-Dunning Alerts With Intercom Series

Series is Intercom's multi-step campaign builder. Use it to catch at-risk accounts before a payment fails.

Build a pre-dunning Series triggered when:

• `card_expiry_month` equals the current month, and `card_expiry_year` equals the current year

Structure the Series:

1. In-app message (day 0): A banner or chat-style message inside the product — "Your card on file expires this month. Update it to avoid any interruption." Include a direct link to your billing settings page.
2. Email follow-up (day 3): For users who did not click the in-app message, send an email. Intercom's outbound email handles this natively.
3. In-app message — escalated (day 7): If the card has not been updated and expiry is now this week, send a more urgent message.

Exit users from the Series as soon as `card_expiry_month` no longer matches — meaning they've updated their card. This requires updating the Intercom attribute in real time from your billing webhook.

Step 3: Trigger Post-Failure In-App Messages

When a payment fails, your billing system fires a webhook. Use that event to update `payment_status` to `past_due` and `failed_payment_count` in Intercom immediately.

Build a second Series or use Intercom's event-triggered messages to react to this:

• Trigger: Custom event `payment_failed` sent via Intercom's Events API
• Message type: In-app post — a full-screen or modal message that appears when the user next logs in

The message should do three things: state the problem clearly, remove ambiguity about what happens next, and give one obvious action. "Your last payment didn't go through. Update your billing details to keep your account active — takes under a minute."

For users with `failed_payment_count` greater than 1, change the message tone. The second and third failure messages should be more direct about account suspension timelines.

Step 4: Use Product Tours for Payment Update Guidance

Some users get stuck not because they lack motivation, but because navigating to billing settings inside a complex product takes effort. Product Tours in Intercom solve this.

Build a short Product Tour (3-5 steps) that:

1. Highlights the account menu or settings icon
2. Points to the billing section
3. Surfaces the payment method update field
4. Confirms completion with a tooltip

Trigger this tour from within your dunning in-app messages using a deep link with the `?intercom_tour_id=XXXX` parameter. The user clicks your CTA, lands on the settings page, and the tour starts automatically.

Step 5: Segment by Account Value and Urgency

Not every dunning message should be identical. Use Intercom's Segments to split your approach:

• High-value accounts (e.g., `plan_mrr` greater than $500): Route these to a Conversation in Intercom so a CSM can reach out personally alongside the automated messages
• First-time failures: Softer messaging, emphasize that it's likely a simple card issue
• Accounts within 48 hours of cancellation: Maximum urgency, surface a Chat message from a real person rather than a bot

Intercom's Custom Bots can handle the triage here — ask the user if they need help updating their payment, and route them to a human rep or self-service flow depending on their response.

---

Limitations to Know Before You Build

Intercom is strong on delivery and weak on payment logic. Be clear-eyed about what it cannot do:

• No native retry logic: Intercom cannot trigger a charge retry. That must live in your billing system. Intercom's only job is messaging.
• Attribute sync lag: Real-time payment state requires you to push updates via API immediately on billing events. If your sync is batched or delayed, your messages will be mistimed.
• No native SMS: If your users are not logging into the product during a dunning window (common for churned or low-engagement users), Intercom's in-app channel does nothing. You will need email or SMS from another platform for those users.
• Email deliverability at scale: Intercom email is reliable for transactional messages but is not optimized for high-volume dunning sequences. For large user bases, consider routing dunning emails through a dedicated ESP.
• Limited A/B testing in Series: Intercom's Series builder does not offer robust split-testing on message variants. You will have limited ability to optimize messaging performance without manual iteration.

---

Frequently Asked Questions

Can Intercom handle the entire dunning flow on its own?

No. Intercom handles the messaging layer — reaching users, delivering context, and driving them to take action. The retry logic, payment state management, and billing operations need to live in your billing platform (Stripe, Chargebee, Recurly, etc.). Intercom and your billing system need to exchange data in real time via webhooks and API calls for the full flow to work.

What is the most effective Intercom message type for dunning recovery?

In-app posts and banners consistently outperform email for users who are actively logging into the product. A full-screen in-app post on the first login after a payment failure gets seen and acted on faster than an email. For users who have not logged in within 48 hours, in-app messaging is irrelevant — shift those users to email immediately.

How do I stop sending dunning messages once someone has paid?

Update the `payment_status` attribute on the Intercom user record to `active` as soon as your billing system confirms a successful payment. Build exit conditions in your Series that check this attribute. Any user whose status returns to `active` exits all active dunning campaigns immediately. Do not rely on manual cleanup — this must be automated via your billing webhook.

How do I measure whether my Intercom dunning messages are working?

Track three numbers: open rate on in-app messages, click-through rate to your billing update page, and recovery rate — the percentage of `past_due` accounts that return to `active` within your dunning window. Intercom's reporting shows message engagement. Recovery rate requires pulling payment state data from your billing system and joining it to cohorts you targeted. Build a simple dashboard that connects both data sources.