How to Build n8n Contract Renewal Reminders That Don't Spam Accounts

A customer contract renews in sixty days and nobody's started the conversation. The CSM is heads-down, the renewal date lives in a spreadsheet column nobody sorts by, and the first time anyone notices is the week it lapses. n8n contract renewal reminders turn that silent countdown into a tiered set of nudges that reach the right person early enough to actually save the account.

Most of what ranks here is pointed at the wrong team. n8n's vendor contract renewals template is built for procurement chasing their vendors, single-trigger, no dedupe. ClearContract's renewal-automation walkthrough and Invulnerable's expiring-contract-alerts use case describe the general idea. None of them handle the customer-success angle with the two pieces that make a daily scan livable: tiered thresholds, and a dedupe guard so the same account isn't pinged every morning for a month.

The dedupe guard is the feature

Here's the opinion that decides whether this workflow ships or gets disabled in week one: a renewal reminder without a sent-tier guard is a spam machine. A naive daily Cron that emails every account inside 30 days will email each of them every day for thirty days. The account owner mutes the alerts by day three, and now the automation is worse than nothing, because everyone's learned to ignore it. Tier the reminders, track which tier each account has received, and send each one exactly once.

That's the whole difference between a tool people trust and noise they filter.

What you can automate in renewal reminders

• Scan every active contract once a day for upcoming renewals
• Compute days-until-renewal as a clean integer per account
• Fire tiered alerts at 90, 30, and 7 days before the date
• Route each tier to the right owner (CSM at 90, manager at 30)
• Track which reminder tier each account has already received
• Draft the renewal outreach with the account's context filled in
• Log every reminder for an auditable renewal trail

The date-math and the sent-tier tracking are the two steps the ranking templates skip. They're also the two that keep the inbox sane.

The renewal-reminder pipeline

Schedule (Cron, daily 6am)
  → Read active contracts (Sheets / CRM)
  → Code (days_until_renewal per record)
  → Switch (90 / 30 / 7 day tier)
  → IF tier already sent?  → skip
  → Send + route by tier
  → Stamp last_reminder on the record

Scan, compute, tier, guard, send, stamp. The guard before the send is what stops the daily repeat.

1. Scan on a schedule

A Cron trigger firing once a day (6am is the common choice, before anyone's working the accounts) reads the active contracts from wherever they live, a Google Sheet, a CRM custom object, a database. Pull the renewal date, the account owner, and a last_reminder field you'll maintain.

Daily is the right cadence. Hourly is pointless for a date that moves once a day, and it just multiplies the chances of a dedupe slip.

2. Compute days-until-renewal once

The date-math the descriptive guides hand-wave. Do it in one Code node so every threshold check reads the same number:

const MS_DAY = 86400000;
const today = new Date(); today.setHours(0,0,0,0);
return $input.all().map(item => {
  const renew = new Date(item.json.renewal_date);
  const days = Math.round((renew - today) / MS_DAY);
  return { json: { ...item.json, days_until_renewal: days } };
});

Now days_until_renewal is an integer you branch on cleanly. Negative means already lapsed, which is its own (urgent) branch.

3. Tier with a Switch

A Switch node maps the day count to a tier. The standard ladder for B2B contracts: 90 days to open the renewal conversation, 30 days to escalate to the account owner, 7 days as the final internal alert. Match on a small window around each (say 88 to 92 for the 90-day tier) so a record that's scanned a day late still catches its tier instead of falling through the gap.

days <= 7   → tier 7   (final internal alert)
days <= 30  → tier 30  (escalate to owner)
days <= 90  → tier 90  (open the conversation)

Evaluate tightest-first so a 5-day contract hits tier 7, not tier 90.

4. The sent-tier guard

This is the node that makes the daily scan survivable. Read last_reminder off the record. If the account has already received the tier this run would send, skip it:

const due = $json.tier;                 // 90, 30, or 7
const sent = Number($json.last_reminder || 999);
// only send if we haven't already sent this tier or a closer one
if (sent <= due) return [];             // already nudged at this tier or nearer
return [{ json: $json }];

Without this, the account inside the 30-day window gets pinged every morning. With it, the 30-day reminder fires once, the day the account crosses 30, and stays quiet until the 7-day tier comes due. Stamp last_reminder to the tier you just sent, after the send succeeds.

5. Send and route by tier

Each tier goes to a different recipient with different urgency. The 90-day reminder might draft a friendly "let's talk renewal" email to the CSM; the 30-day escalates to the account owner with the account's usage context; the 7-day is an internal Slack alert, not a customer email. An OpenAI node can draft the outreach with the account name, contract value, and tenure filled in, so the CSM edits rather than writes from scratch.

Implementation patterns

Pattern A — the at-risk weighting. Not every renewal deserves the same energy. Cross-reference the renewal scan with a health signal (usage trend, support-ticket volume, last login) and bump at-risk accounts to an earlier, louder tier. A healthy account at 30 days needs a polite nudge; a quiet, declining account at 90 days needs the CSM on a call this week. Generic date-only reminders treat both the same, which wastes attention on the safe ones and under-serves the shaky ones.

Pattern B — the lapsed-contract catch. A separate branch for days_until_renewal < 0 fires an urgent escalation, because a contract that slipped past its date is revenue actively leaking. Most reminder workflows only look forward and never notice the one that already lapsed. The negative branch is cheap and catches the most expensive miss.

n8n nodes you'll use most

Getting started

1. Set a Cron trigger for a daily early-morning scan.
2. Read active contracts with renewal date, owner, and a last_reminder field.
3. Compute days_until_renewal in one Code node so every check agrees.
4. Tier the count with a Switch, evaluating tightest threshold first.
5. Add the sent-tier guard so each tier fires once per account.
6. Route and send per tier, then stamp last_reminder after success.
7. Add the at-risk weighting and the lapsed-contract branch.

For the customer-side renewal and retention motion this feeds, the Membership Churn Recovery Engine template scores every account daily for risk and fires AI-personalized retention emails by tier, the same scan-score-tier-send rhythm a renewal workflow runs. If your renewals are subscription billing rather than contracts, the Smart Subscription Manager template audits active Stripe subscriptions and schedules a review.

A renewal you see coming ninety days out is a renewal you keep. Compute the date-math cleanly, tier the reminders to match how urgency builds, and guard against the daily repeat so the alerts stay worth reading. The same accounts you're renewing are the ones worth watching for churn signals, covered in How to Predict Churn with an n8n Customer Health Score, and the quiet ones are what How to Prevent Churn with n8n addresses head-on. Scan daily, tier the nudges, send each once.