What this automation does
Once a week, every account owner gets a short list of customers who need attention, why, and what to do about it.
- Collect signals. A scheduled job pulls usage from your product database (logins, active users, key actions), billing from Stripe or Chargebee (failed payments, downgrades, seats removed, renewal dates), support from Zendesk (ticket volume, open escalations) and ownership from HubSpot.
- Join on one account ID. The job maps each system’s customer identifier to a single account record. This is the step that takes the most care.
- Score with rules. Each account gets points for specific signals: active users down sharply from their trailing average, a failed payment, a seat reduction, renewal within 60 days with low usage, several tickets in two weeks.
- Read the conversations. For accounts above a threshold, or with any recent ticket or call note, a model reads the recent text and returns tagged concerns with short supporting quotes.
- Write the alert. For each flagged account, the model writes a two-line reason from the triggered rules and tags, and suggests one next step from a list you defined (check-in call, training session, executive outreach, billing follow-up).
- Deliver and track. Each owner gets a Slack digest with links to the CRM record. A “handled” button logs the action taken, which feeds the quarterly accuracy review.
When it is worth building
This makes sense once losing a single account matters and you have more accounts than owners can watch closely. That is usually the point where account owners stop noticing that a customer quietly went from twenty active users to six.
You need some data hygiene first. If usage data is not available or customer IDs cannot be matched across billing and product, start with that data work, possibly with natural-language SQL reporting on top. If you already pay for a customer success platform with health scores, use that and feed it better signals instead of building a parallel system. For theme-level insight across all customers rather than per-account alerts, see AI customer feedback analysis.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Usage data | Your product database (Postgres) or analytics warehouse | The strongest churn signals usually come from how the product is used |
| Billing data | Stripe or Chargebee | Failed payments, downgrades and renewal dates are concrete and timely |
| Support and notes | Zendesk tickets and HubSpot notes and emails | The unstructured text where customers say what is wrong |
| Orchestration | n8n on a weekly schedule, plus webhooks for severe signals | Built-in Stripe, HubSpot, Zendesk, Postgres and Slack nodes; Chargebee through its trigger node for webhooks and the HTTP Request node for data its built-in node does not cover |
| Account mapping | A mapping table in Postgres | One reliable account ID across every system |
| Scoring | SQL and a code step with documented rules | Owners can see exactly why an account was flagged |
| Text analysis | Claude Sonnet 5.5 with structured output | Reads ticket and note history and returns tags with quotes, not opinions |
| Delivery | Slack digest per owner with a handled button | Alerts land where owners work, and actions are recorded |
How to build it
- List last year’s churned and downgraded accounts and, with the account owners, write down what happened in the 90 days before each. This gives you candidate signals grounded in your own history.
- Build the account mapping table linking product, billing, support and CRM IDs. Expect to fix mismatches by hand for a share of accounts.
- Write five to eight rules with point values, each tied to a signal you saw in the churn history. Keep the logic simple enough to explain in a sentence.
- Back-test the rules against last year’s data. Check how many churned accounts would have been flagged in advance, and how many healthy accounts would have been flagged too.
- Build the text analysis step with a fixed tag list (feature gap, competitor mentioned, champion change, budget, service failure, positive expansion signal) and require a quote for every tag.
- Build the digest with a cap per owner, such as the top ten accounts, so it stays readable.
- Run for a month with CS leadership only, review every flagged account together, then roll out to all owners.
The downloadable starter template below covers the weekly schedule, Stripe and Zendesk signal collection, AI ticket review and the Slack digest.
What breaks in production
- Alert fatigue. Too many flags and owners stop reading. Cap the digest, raise thresholds, and remove any rule that flags many accounts that never churn.
- ID mismatches. A customer’s billing account and product workspace do not match, so usage shows zero and the account is falsely flagged. Alert on unmapped accounts separately rather than scoring them.
- Seasonality. Usage dips in August or over the holidays look like disengagement. Compare against the same account’s pattern from a year ago where you have it, or against the full customer base for the same week.
- One angry ticket. The model tags strong frustration from a single bad day. Weight text signals by recency and repetition, and never flag an account from one ticket alone unless it mentions cancelling.
- Small accounts with noisy data. A three-user account dropping to two users is a big percentage change and means little. Use absolute thresholds for small accounts.
- Nobody owns the alert. Accounts without an assigned owner in the CRM produce alerts that go nowhere. Route unowned accounts to a team lead.
Timeline and cost
A first version with three or four data sources, a rule set and weekly digests typically takes two to four weeks. Lumeor builds churn risk alerts in the range of $6,000 to $12,000. The low end assumes product usage is already in a queryable database and IDs mostly match. The high end includes building the account mapping, back-testing the rules against historical churn and adding real-time alerts for severe signals. Model costs depend on how much ticket and note text is reviewed each week and are usually small.
How to measure success
- Alert precision: share of flagged accounts that churned, downgraded or were confirmed at risk by the owner
- Early warning coverage: share of churned accounts flagged at least 30 days before they left
- Time from alert to owner action, from the handled button
- Gross revenue retention, quarter over quarter, keeping in mind it moves slowly and has many causes
- Rules retired or changed per quarter, a sign the system is being tuned rather than ignored