Churn Signal Analyst

By the time the cancellation email arrives, the account left months ago: usage thinned, the champion stopped logging in, support tickets turned terse. This skill mines usage, billing, and support data for those earlier signals, compares churned accounts against retained look-alikes, and produces a transparent risk score with reason codes — so retention work starts while there is still someone to retain.

When to use this skill

• Retention is slipping and the team reacts to cancellations instead of anticipating them
• Building or refreshing the at-risk list that customer success works each week
• Post-mortem on a bad churn quarter: what did the lost accounts share, and when did it first show?
• Deciding which events and properties the product should log so future churn analysis is possible

Workflow

1. Define churn precisely before touching data. The event — cancellation, non-renewal, payment stop, or usage at zero for N weeks — the population (paying accounts past onboarding), and the observation window. Sloppy definitions here quietly decide every downstream conclusion.
2. Assemble account-level features across three planes. Usage: trend over trailing weeks, breadth (features touched, active seats versus paid seats), depth (core-action frequency), recency. Relationship: champion login recency, admin turnover, ticket volume and tone trajectory, unanswered check-ins. Commercial: plan changes, failed payments, renewal proximity, discount history.
3. Compare churned accounts to retained look-alikes, matched on segment, plan, and tenure — not against the whole base. The interesting differences appear before the churn event, and lead time matters as much as the signal itself: a flag that fires two weeks before cancellation is a coroner, not a doctor.
4. Distill the leading indicators. Keep signals that are observed meaningfully more often in churned accounts, visible with useful lead time — aim for 60 to 90 days — and actionable. A team can do something about "seat activity down 40 percent quarter over quarter"; it can do nothing about "account is small".
5. Build a transparent score, not a black box. Points per signal, weighted by observed lift, summed into risk tiers. Every scored account carries its reason codes — "champion inactive 30 days; breadth down to two features; renewal in 45 days". A score nobody can explain is a score nobody will act on.
6. Backtest before shipping. Run the score against a past period it was not built on. Of the accounts it would have flagged, how many churned? Of the accounts that churned, how many did it flag in time? Report both, plus the false-alarm workload per customer-success head, because an alarm that cries wolf gets muted within a month.
7. Wire it to action and feedback. Map each risk tier to a play: executive check-in, training push, pricing conversation. Log intervention outcomes so the next revision learns which saves work — and note that once teams act on the score, churn among flagged accounts stops being a clean measure of accuracy. That contamination is the goal; record it in the evaluation notes.

Output format

Three artifacts: the signal catalog — signal, definition, observed lift, typical lead time; the scoring spec — points, tiers, reason-code format; and the weekly risk register — account, tier, score, reason codes, days to renewal, assigned play, owner.

Guardrails

• Correlation caution: low usage may be the symptom of a decision already made, not its cause — signals are smoke detectors, not explanations
• Small-n humility: under a few dozen churn events, ship a pattern-informed checklist, not a model
• Seasonality check: compare against the same period last year before declaring any trend
• Never auto-trigger customer-facing messages from the score without human review; a mistimed "we noticed you're leaving" email creates the churn it predicted
• Revisit quarterly — product changes shift what healthy usage looks like, and stale scores rot silently while still printing numbers