How to Automate Inactive Customer 30 Days → Re-engagement Email + CS Alert with n8n

Every SaaS and e-commerce business has a silent leak: customers who stop showing up. They don't cancel, they don't complain — they just go quiet. Thirty days of no logins, no purchases, no support tic

How to Automate Inactive Customer 30 Days → Re-engagement Email + CS Alert with n8n

Every SaaS and e-commerce business has a silent leak: customers who stop showing up. They don't cancel, they don't complain — they just go quiet. Thirty days of no logins, no purchases, no support tickets. By the time it shows up in your churn report, they're already gone. This article walks through building an automated system in n8n that catches these customers at the 30-day inactivity mark, fires a re-engagement email, and alerts your customer success team so a human can step in before the account is lost.

The Problem: Churn Is a Lagging Indicator

Most teams measure churn after it happens. A customer's subscription lapses, or their MRR drops to zero, and only then does the number turn red on a dashboard. The trouble is that by that point there is nothing left to save — the relationship ended weeks earlier, quietly, the moment they stopped getting value.

Inactivity is the leading indicator you actually want to watch. A customer who hasn't logged in, placed an order, or triggered an event in 30 days is dramatically more likely to churn than one who was active last week. But nobody has the time to manually cross-reference last-activity dates across hundreds or thousands of accounts every morning. So it doesn't get done, and the leak keeps dripping.

The other failure mode is over-alerting. Teams that do try to monitor activity often flood their CS reps with noise — every dip in usage becomes a fire drill, reps burn out, and real signals get ignored. What you need is a precise, scheduled check that only surfaces genuinely at-risk accounts and pairs each alert with an automated first touch, so the human effort is reserved for the cases that warrant it.

The Solution: A Scheduled Inactivity Watchdog

The workflow does three things on a fixed cadence, with zero manual effort:

  • Detects customers whose last activity timestamp crossed the 30-day threshold — no earlier (too twitchy), no later (too late).
  • Re-engages them automatically with a personalized email designed to pull them back in, not just remind them you exist.
  • Alerts customer success in Slack (or your tool of choice) with the account context, so a rep can decide whether a human follow-up is warranted.

The key design principle is the 30-day window, not a 30-day floor. You want customers who became inactive exactly around day 30 — catching a customer who's been gone 90 days is a different (and usually lost) play. The workflow filters for a tight band so the same customer doesn't get pinged every single day after they cross the line.

Step-by-Step Setup in n8n

Here's how the nodes wire together. The whole thing runs headless on a schedule and takes about 20 minutes to configure once you have your data source connected.

1. Schedule Trigger. Start with a Schedule Trigger node set to run once daily — early morning (e.g. 07:00) is ideal so alerts land before the CS team starts their day. Use the "Days" interval with a value of 1. Avoid running it more frequently; daily is the right granularity for a 30-day metric and keeps you from double-emailing.

2. Fetch customers and their last-activity date. Add a node that pulls your customer list with a last-activity or last-order timestamp. This is your one integration point — it could be a Postgres / MySQL node running a query like SELECT id, email, name, last_active_at FROM customers WHERE last_active_at IS NOT NULL, an HTTP Request node hitting your product API, or a Stripe / HubSpot node reading customer records. If you're on a CRM, pull the "Last Activity Date" field directly.

3. Compute inactivity and filter the window. Add a Code node (or a Filter node with an expression) to calculate the gap in days and keep only the target band. In a Code node:

const now = Date.now();
return items.filter(item => {
  const last = new Date(item.json.last_active_at).getTime();
  const days = Math.floor((now - last) / 86400000);
  return days >= 30 && days <= 32;
});

The 30–32 day band is what keeps the workflow from re-alerting the same customer every day. Because the daily schedule advances one day at a time, each inactive customer falls inside this window for roughly three runs — tighten it to days === 30 if you want exactly one touch per customer and are confident your schedule won't miss a day.

4. Split into batches (optional but recommended). Insert a Loop Over Items (Split in Batches) node so you process customers one at a time. This prevents rate-limit errors from your email provider and makes the CS alerts readable rather than one giant blob.

5. Send the re-engagement email. Add your email node — Send Email (SMTP), Gmail, SendGrid, or Postmark. Personalize the subject and body with expressions like {{ $json.name }}. Keep the copy short and value-led: acknowledge you've noticed they've been away, offer one concrete reason to return (a new feature, an unfinished setup step, a limited incentive), and include a single clear CTA. One button, one action.

6. Post the CS alert. In parallel, add a Slack node (or Microsoft Teams / Discord) pointed at your customer-success channel. Include the customer name, email, days inactive, plan tier, and a link to their account in your CRM. Message the rep the decision they need to make, not just raw data — e.g. "⚠️ Acme Corp (Pro, $290/mo) inactive 31 days. Re-engagement email sent. Worth a personal check-in?"

7. Log the touch. Finally, write back to your data source — a Set node followed by an update node (Postgres/HubSpot/Airtable) that stamps a reengagement_sent_at field. This gives you an auditable record and a safety net against duplicate outreach if you ever widen the day band.

The Benefits: Compounding, Not One-Off

The immediate win is obvious — you recover customers you would otherwise have lost silently. But the second-order benefits are where this pays off:

  • CS time goes to high-value work. Reps stop hunting for at-risk accounts and start closing save conversations. The workflow does the surveillance; humans do the judgment.
  • Every save is high-margin. Retaining an existing customer costs a fraction of acquiring a new one. A workflow that recovers even a handful of accounts a month pays for itself many times over.
  • You build a churn early-warning dataset. Because you're logging every re-engagement touch, you can start measuring which segments respond, what copy converts, and how predictive the 30-day mark really is for your business.
  • It runs whether or not anyone remembers. No dependency on a person checking a dashboard. The leak gets plugged every single day, automatically.

Common Pitfalls to Avoid

Re-emailing the same customer daily. This is the number-one mistake and the fastest way to get flagged as spam. The day-band filter (30–32) plus the reengagement_sent_at log are your two defenses — use both. If a customer already has a recent timestamp in that field, skip them with a Filter node before the email step.

Timezone drift in date math. Storing timestamps in one timezone and computing "days ago" in another will shift your window by a day and cause off-by-one misfires. Standardize on UTC everywhere — in your database and in the Code node — and only localize for display.

Treating a 90-day-gone customer like a 30-day one. The workflow deliberately targets the fresh-inactive band. Someone who vanished three months ago needs a different, harder-hitting win-back sequence — don't let them slip into the same gentle nudge.

No error handling on the email node. If your email provider hits a rate limit mid-batch, the run can fail silently and CS never gets alerted. Enable "Continue On Fail" on the email node, and add an Error Trigger workflow that pings you when a run breaks so the watchdog itself is monitored.

Generic copy. "We miss you" converts poorly. The email needs one specific, personalized reason to come back — tie it to what that customer was actually doing before they left. Pull a usage signal or unfinished action into the message where you can.

Set this up once and it becomes a permanent, invisible layer of retention infrastructure — quietly catching the customers who were about to slip away, every day, without anyone having to remember.

Inactive Customer 30 Days → Re-engagement Email + CS Alert
PRONTO PARA USAR

Ja construimos isso pra voce

Nao comece do zero. O Inactive Customer 30 Days → Re-engagement Email + CS Alert e um workflow n8n pronto para instalar — conecta suas ferramentas em minutos, sem codigo.

Instalar por $29 →