Activated Cloud
← App Store

Churn Risk Signals

Activated Cloud✓ Officialactivated/churn-risk-signals

No ratings yet0 installsv1.0.0Updated Oct 6, 2026● Unknown

Free · MIT

About

Finds the customers likely to leave before they say so: combines usage, support, billing, relationship and contract signals into a documented health score, flags at-risk accounts with dated evidence, back-tests the score against past churn, and hands the owner a ranked watchlist with the reason and a suggested action for each. The analyst does not contact customers. Use for a weekly risk review, before renewals, or after churn rises. Not for handling a customer who has asked to cancel (use cancellation-save-offer) or survey analysis (use nps-csat-analysis).

Customer Support

Documentation

From SKILL.md · v1.0.0 · what the agent reads when it loads this skill3 files: SKILL.md, references/CREDITS.md, references/health-score-model.md

Churn Risk Signals

If you only start thinking about churn when a customer says they are leaving, it is usually too late. You watch for the accounts going quiet and say which ones, why you think so, and what might bring them back. Early and specific beats late and certain. The standard: every flag cites dated evidence, the scoring rules are written down and tested against customers who actually left, and the list reaches the owner every week in a form they can act on in minutes.

When to use

  • "Which customers are at risk of leaving?"
  • "Build us a customer health score."
  • "Churn went up last quarter; what did we miss?"
  • "Give me the at-risk list before the renewal meeting."
  • A weekly review, scheduled with cronjob.

What you need

  • The customer list with plan, revenue, start date, renewal or contract end date and owner (CRM as a connected app, or an export).
  • Product usage per account over time: active users, logins, key actions, volume. From connected analytics such as PostHog or Mixpanel, the owner's admin dashboard in the browser, or exports. Without usage data the score is much weaker; say so.
  • Support history: ticket counts, open urgent tickets, satisfaction scores, sentiment (connected helpdesk such as Intercom, or exports).
  • Billing: failed payments, downgrades, scheduled cancellations, plan changes (Stripe if connected, or the owner).
  • Relationship: last meeting, contacts who left, unanswered outreach (CRM, mailbox, account plans).
  • The customers who churned in the last 12 months, with dates, for back-testing.

Method

  1. Define churn for this business with the owner: cancellation, non-renewal, a downgrade beyond a threshold, or (for usage-based products) usage falling below a level. Write it down; everything else is measured against it.
  2. Gather signals per account with execute_code, as of today and 30, 60 and 90 days ago, so you can see trends. The full list is in references/health-score-model.md. Core early-warning signals:
    • usage falling 20 percent or more over 30 days with no seasonal reason (a sudden drop of 30 percent or more is a strong flag);
    • only one or two active users (a single point of failure);
    • no login or key action for 14 days or more;
    • products or features paid for but unused;
    • support tickets spiking, urgent tickets unresolved, or poor satisfaction scores;
    • the champion or account owner left, changed role or was removed as an admin;
    • a failed payment, especially with no response;
    • visits to billing or cancellation pages, a data export request, questions about contract terms or notice periods;
    • renewal within 90 days combined with any negative signal;
    • outreach unanswered for 14 days or more, or no meeting in 90 days for accounts that normally meet;
    • company news: acquisition, layoffs, funding trouble, a new leader in the buying role.
  3. Build a simple, documented score.
    • Group signals into usage, support experience, relationship and commercial.
    • Rate each measure healthy, concerning or poor using thresholds written in the model.
    • Weight the groups; a starting point is usage 50, support 20, relationship 15, commercial 15.
    • Keep it explainable: the owner should see why any account scored what it did. Some events override the score and flag the account at once: the customer says they are evaluating alternatives; a data export request; a failed payment with no response; the champion leaving with no replacement contact.
  4. Back-test before trusting it. Score the customers who churned in the last 12 months as they looked 60 to 90 days before they left, and score a sample of customers who stayed. Report:
    • catch rate: of churned customers, how many the score would have flagged;
    • precision: of flagged customers, how many actually churned. If the score misses most churners, find which signals they showed and adjust; report what you changed. With fewer than about 10 churned customers, say the test is indicative only.
  5. Rank the watchlist by risk level and revenue at stake. For each at-risk account write:
    • risk level, revenue and renewal date;
    • the top 3 reasons, with evidence and dates, and since when;
    • what has already been tried;
    • a suggested action and who should act (the account owner, the support lead or the owner). Match the action to the cause: low adoption needs training or a working session; a support problem needs the issue fixed and followed up; a lost champion needs a new relationship; a price concern needs a conversation about right-sizing.
  6. Respect the boundary. You bring the list to the owner and the account owners; you do not contact customers yourself. If a suggested action involves a message, write it as a suggestion for the account owner, not a draft to send.
  7. Report weekly on a show_card:
    • new flags this week, and accounts that recovered;
    • accounts at risk for 4 or more weeks without improvement (these need escalation or an honest decision);
    • revenue at risk by renewal month. Keep the full list in a shared sheet.
  8. Learn from churn. When a customer leaves, write a short retro within a week while details are fresh: what they bought us for; what happened; which signals appeared and when; whether we flagged it and acted; the stated and the real reason; what we would do differently. Track churn reasons over time, and separate the ones the business can influence (adoption, support experience, missing features, a lost champion) from those it cannot (acquisition, closure).
  9. Report retention metrics with consistent definitions:
    • logo churn rate = customers lost in the period / customers at the start;
    • revenue churn, and gross and net revenue retention, for the same cohort (the starting revenue base, excluding new customers in the period). State the period every time.
  10. Improve the model quarterly. Compare flags with outcomes, retire signals that predict nothing, add ones that churners showed. Keep the model file versioned with dates.

Worked example: one watchlist row

Acme Ltd | revenue 24,000 | renews 15 Jan | score 34 (at risk, was 61 four weeks ago) Reasons: active users fell from 9 to 2 since 1 Sept (usage export); champion Tom Reid left on 12 Sept (LinkedIn, CRM); 3 unresolved tickets about exports, oldest 19 days (helpdesk). Tried: support replied to tickets; no account manager contact since July. Suggested: account owner to fix the export tickets this week, then ask the remaining admin who now owns the tool and offer a re-onboarding session. Owner to decide whether to involve the executive sponsor before the renewal conversation at 90 days.

Output

  • The health model document: signals, thresholds, weights, overrides, back-test results, version and date.
  • The weekly watchlist (a sheet) and summary card.
  • Churn retros and a quarterly churn-reasons summary.
  • Retention metrics with definitions.

Checks before you finish

  • Every flag has dated evidence; no flag rests on a single ambiguous data point without saying so.
  • The model was back-tested, and the results are reported honestly, including what it misses.
  • Seasonal businesses were checked against the same period last year before a drop was called.
  • No customer was contacted by you.
  • Definitions and periods are stated for every metric.

Pitfalls

  • Lagging signals only. By the time revenue drops, the decision is made. Weight leading signals: usage trend, active users, champion changes.
  • A black-box score. If nobody can explain a red flag, nobody acts on it. Keep it simple and visible.
  • Flag fatigue. Flag half the base and the list is ignored. Tune thresholds so the list is short enough to act on.
  • Confusing quiet with unhappy. Some healthy customers never talk to you. Check usage before assuming the worst; check the relationship before assuming the best.
  • No feedback loop. A model never compared with real churn is a guess with decimals.

See also: cancellation-save-offer, nps-csat-analysis, customer-onboarding-plan.

Versions

v1.0.0currentOct 6, 2026

Listed from the source repository.

Reviews

No reviews yet. Be the first.

Write a review