Churn Risks
Named at-risk accounts, root-cause analysis of why they're at risk, and the mitigation plan in flight. Pairs with the quantitative `arr_at_risk` and `percent_arr_at_risk` and gives the board the names + the playbook. Common pitfall: listing the at-risk accounts without the diagnosis or the plan — the board reader needs to see what the team is doing about it, not just what the team is worried about. Also: avoid using this surface as a generic "things are bad" venting forum — keep it account-specific and action-specific. — Customers KPI, I'mBoard-authored (editorial tier).
I'mBoard-authored (editorial tier)
No public third-party standard anchors this KPI yet, so I'mBoard authors and maintains the definition — transparently labeled as editorial tier. See the ontology methodology for the published vs editorial tier system and the back-attribution workstream.
Rogue ID: customers.churn_risks
Type: Text
Domain: Customers
Definition
Named at-risk accounts, root-cause analysis of why they're at risk, and the mitigation plan in flight. Pairs with the quantitative arr_at_risk and percent_arr_at_risk and gives the board the names + the playbook. Common pitfall: listing the at-risk accounts without the diagnosis or the plan — the board reader needs to see what the team is doing about it, not just what the team is worried about. Also: avoid using this surface as a generic "things are bad" venting forum — keep it account-specific and action-specific.
Formula
Qualitative — no calculation. Per-account list: account name, ARR exposure, churn driver (usage decline, exec churn, missed milestone, competitive loss, integration friction, etc.), mitigation owner, mitigation plan, next checkpoint date.Why it matters
Converts the dollar exposure (arr_at_risk) into a board-readable narrative of named accounts and concrete plans. Forces the CS team to articulate the diagnosis, not just the symptom.
How to interpret
Anti-pattern: an aggregate "we have $X at risk" with no per-account breakdown. Strong content lists the top 3–5 at-risk accounts by ARR, with cause and plan for each. If the team is asking the board for help (intro, exec sponsor, pricing relief), surface the ask here explicitly — boards routinely catch resolvable churn that the team would not have escalated.
Related KPIs
customers.arr_at_riskcustomers.percent_arr_at_riskcustomers.top_customer_concentrationcustomers.retention_insightscustomers.key_initiatives
Source
I'mBoard editorial — authored and maintained by I'mBoard, first published 2026-04-01. No third-party standard is cited for this KPI; when one emerges, the definition is back-attributed and promoted to the published tier (a minor version bump). Read the ontology methodology for the published vs editorial tier system, attribution rules, and dispute process.
Stage relevance
| Company stage | Priority |
|---|---|
| Series A | Core |
| Series B | Core |
| Series C+ | Core |
| Public | Core |
Suggested for stages: Series A, Series B, Series C+, Public.
Default owning functions
- Sales
Machine-readable
- This KPI as JSON:
/api/ontology/customers/churn_risks.json - All Customers KPIs:
/api/ontology/customers.json - Full catalog:
/api/ontology/index.json
ARR at Risk
Sum of ARR from customers flagged "at-risk" by the customer-success team — typically driven by usage decline, low health score, executive turnover at the customer, missed milestones, or explicit churn intent. The board reads this as the worst-case near-term churn exposure if no intervention happens. Common pitfall: the "at-risk" definition drifts across CSMs and quarters; standardize the criteria (e.g. health score below threshold OR 30-day usage drop > X% OR cancellation request received) and version-control the playbook so the absolute number is comparable period-over-period. Pair with `percent_arr_at_risk` for the proportional read. — Customers KPI, I'mBoard-authored (editorial tier).
Customers Churned
Count of customer logos that ended their subscription/contract during the period. Includes voluntary cancellations and non-renewals. Some companies separately track downgrade-to-zero as churn — be explicit about whether downgrades that drop ARR to $0 count as churn (typical: yes) vs. material contraction that keeps ARR > 0 (typical: tracked under contraction, not churn). The board reads this as the raw count behind `logo_churn_rate`; the percentage tells you the rate, the absolute count tells you the volume of CS pain. Common pitfall: counting customers that re-activate (sometimes called "boomerang" or resurrection) — settle the rule (typical: count each cancellation event, do not net resurrection). — Customers KPI, I'mBoard-authored (editorial tier).