Detecting customer churn risk with an AI risk score in n8n

Most teams find out a customer is about to cancel the moment they announce it — too late to act. The signal existed weeks earlier, scattered across the billing tool, the CRM and the support tickets, but nobody has time to cross-reference these three sources account by account, every week. An n8n workflow that aggregates these signals and computes an AI-driven risk score changes that dynamic: instead of discovering churn after the fact, the team gets an alert while there's still room to act.

This guide covers voluntary churn — a customer who disengages and then consciously cancels. For involuntary churn (an expired card, a declined payment), the logic is different and already covered in our article on handling failed payment follow-ups with n8n and Stripe: the two pipelines are complementary, not redundant.

Why a composite score beats a single indicator

A study by Dias & António (2025), Predicting customer churn using machine learning: A case study in the software industry, published in the Journal of Marketing Analytics (Google Scholar page), compared several churn-prediction models on data from a software vendor. The most useful finding for building a pipeline isn't the best-performing model (XGBoost, in their case), but the factors that weighed most heavily in the prediction: support ticket resolution time, license tenure, application type, and the number of open incidents per customer. None of these signals alone is enough to predict a departure — it's their combination that produces a reliable score. That's exactly what an n8n pipeline can reproduce, without a custom-trained machine learning model: an AI Agent that weighs several structured signals against explicit rules.

Pipeline overview

Four building blocks: scheduled collection of signals per account, score computation by an AI Agent with structured output, routing based on risk level, then logging to track evolution over time. This is a similar architecture to the support ticket scoring pipeline, applied here not to a single ticket but to a customer account as a whole, recalculated periodically rather than on every event.

Step 1 — Collect risk signals, account by account

A Schedule Trigger node (n8n-nodes-base.scheduleTrigger), running nightly or weekly depending on account volume, starts the workflow over the list of active subscriptions. For each account, three sources are cross-referenced:

• Subscription — via the native Stripe node or an HTTP Request against the Stripe API: subscription tenure, plan, recent invoice.payment_failed history, a recent downgrade.
• CRM — via the HubSpot or Pipedrive node, as described in our guide to syncing a CRM with n8n: last sales interaction, account status, any mention of dissatisfaction in notes.
• Support — number of tickets opened in the last 30 days and average resolution time, exactly the signals the study above highlights. If your support desk already runs on the ticket scoring pipeline, this data is likely already logged in a Supabase table, and a single query is enough to retrieve it.

A Merge node combines these three streams by account ID, then a Set node normalizes everything into a single object: account_id, tenure_days, plan, failed_payments_90d, open_tickets_30d, avg_resolution_time_h, last_sales_interaction.

Step 2 — Compute the score with an AI Agent and structured output

An AI Agent node (@n8n/n8n-nodes-langchain.agent) receives this normalized object and produces a score through a Structured Output Parser (@n8n/n8n-nodes-langchain.outputParserStructured). If the AI Agent node is still new to you, our guide to getting started with n8n's AI nodes covers its basic setup. The expected output schema:

• risk_score — an integer from 0 to 100
• level — a closed enum (low, medium, high, critical)
• factors — the list of signals that weighed most in the score
• recommended_action — a factual sentence (informational nudge, CSM call, no action)

The system prompt should set an explicit scoring rubric, mirroring what the study reveals: a lengthening resolution time, short tenure combined with repeated tickets, or a recent downgrade should weigh more than plain commercial silence. Also specify that the model must justify each score in the factors field — a critical score without a clear justification should stay suspect to the team reviewing the queue, exactly as with ticket scoring.

Step 3 — Route based on risk level

A Switch node routes based on level:

• critical or high — a Slack alert goes to the Customer Success channel with the score, the factors and a direct link to the CRM account record; in parallel, a task is created in HubSpot or Pipedrive so a human CSM takes over. This is the same reflex as the urgency alert in the Pack Inbox IA (€79) — routing human attention toward what matters, without automating the decision itself.
• medium — an automated informational follow-up sequence (help content, invitation to a check-in call) can go out without human intervention, on the same principle as the automated follow-ups for incomplete files workflow from the Pack Conformité & Audit.
• low — the score is simply logged, no action triggered.

None of these branches should ever apply a discount, a commercial concession, or a contract change automatically: that kind of decision stays in human hands, using the human-approval pattern with a Wait node and Slack if you still want to prepare a proposal ahead of validation.

Step 4 — Log to track evolution, not just a snapshot

A single score says little; its trend says much more. Every run writes the day's score to a Supabase table (churn_score_history: account_id, score, level, date), as described in our guide to connecting n8n to Supabase. Before sending an alert, the workflow queries this table to check that no alert has already gone out recently for this account, or that the score has moved enough to justify a new nudge — otherwise an account stuck at high risk would generate the same alert every week until nobody reads them anymore.

This table also doubles as an audit trail: who was alerted, when, on which factors. The same traceability reflex detailed in our article on building a GDPR audit trail with n8n and Supabase — particularly relevant here since this data crosses billing, support and sales information about identified individuals.

Limitations to know before production

• The score is a decision aid, not a verdict. An account scored critical deserves a human call that confirms or overturns the diagnosis, not an irreversible automatic action.
• The score is only as good as the source data. A poorly maintained CRM or a loosely wired ticketing tool produces a noisy score; fix the collection layer before tuning the prompt.
• A generic model isn't a machine learning model trained on your own historical churn data. This AI Agent plus explicit-rules approach is a fast, solid starting point; if your account volume justifies it, a dedicated statistical model (like those compared in the cited study) can refine the score further down the line.

Getting-started checklist

• Nightly or weekly Schedule Trigger, depending on active account volume.
• At least three cross-referenced sources: subscription (Stripe), CRM, support — product usage as a bonus signal if available.
• AI Agent with structured output: score, level, justifying factors, recommended action.
• Switch that alerts a human on high risk levels, never automating a commercial decision.
• Score history logged in Supabase, with alert deduplication for accounts already flagged recently.

A well-built churn risk score doesn't replace a Customer Success team — it stops them from discovering a cancellation after the fact, giving them the same starting point as a seasoned CSM who cross-references these signals instinctively. The same architecture — multi-source collection, structured AI Agent, routing, logging — shows up across the FlowKit pack workflows; the Complete FlowKit Bundle (€269 instead of €347) bundles all three packs if your automations also cover inbound email and documentation compliance.