I'mBoard API Docs

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).

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.arr_at_risk Type: Currency Domain: Customers

Definition

Formula

arr_at_risk = Σ(ARR of customers flagged at-risk by CS team). The "at-risk" flag itself is a company-specific definition (typical components: health score below threshold, 30-day usage decline, executive churn at customer, missed onboarding milestones, explicit churn signal). Document the flag rule in `customer_definition_note` so the number is comparable across periods.

Why it matters

Converts the qualitative CS pipeline into a board-readable dollar exposure. Forces the team to put a number on hand-wavy customer-health concerns and surfaces concentration risk (a single $500K at-risk account is a different conversation than fifty $10K accounts).

How to interpret

Always present alongside percent_arr_at_risk — $500K at-risk is a 5% problem at $10M ARR but a 0.5% problem at $100M ARR. There is no citation-grade industry benchmark for the absolute number; the >15% destructive threshold the ArrAtRiskGauge widget uses is internal heuristic, not an external standard. Trend month-over-month — sustained growth in arr_at_risk is the leading indicator that NRR will deteriorate next quarter.

Calculation policy

How an AI agent should compute this KPI from messy company data. Free-text rules consumed at reasoning time — not a deterministic DSL. The most common ways to get this wrong are listed under Common miscomputations.

Inclusion rules

Sum the contracted ARR of every customer flagged "at-risk" by the CS team as of the reporting date — a point-in-time exposure snapshot.
Use each at-risk customer's current contracted ARR (the exposure if they churn), consistent with sales.arr's contracted-recurring definition.
The "at-risk" flag is company-specific: standardize and version-control the trigger criteria (e.g. health score below threshold, 30-day usage decline > X%, executive churn at the customer, missed onboarding milestones, explicit churn/cancellation signal).

Exclusion rules

ARR of healthy / not-flagged customers.
One-time fees, services, and non-committed usage — same exclusions as ARR; this is contracted-recurring exposure.
Expansion pipeline or upside — this is downside exposure, not opportunity.
Customers already churned — their ARR is realized loss, not "at risk".

Required inputs

Per-customer at-risk flag with the documented, versioned trigger rule.
Per-customer contracted ARR as of the reporting date.
The at-risk-definition playbook version (so the number is comparable period-over-period).

Data-source priority

CS platform / health-scoring system joined to the ARR ledger by a stable account ID.
Manual CSM at-risk list joined to billing ARR as a fallback — flag the subjectivity.

Edge cases

A single large at-risk account vs. many small ones is a different conversation — surface the concentration alongside (one $500K account ≠ fifty $10K accounts).
At-risk flag toggling on and off within the period: take the flag state as of the reporting date (point-in-time), not the max during the period.
Customer at-risk AND in active expansion talks: still count the full at-risk ARR; the upside is tracked separately.

Validation checks

arr_at_risk ≤ sales.arr — you cannot have more ARR at risk than total ARR.
Present with percent_arr_at_risk (= arr_at_risk ÷ sales.arr); the absolute dollar figure is meaningless without the proportion.
Non-negative.

Common miscomputations

Drifting "at-risk" criteria across CSMs or quarters — the trend then reflects bookkeeping, not customer health; standardize and version the flag.
Using recognized or invoiced revenue instead of contracted ARR for the exposure amount.
Reporting the absolute dollar figure without percent_arr_at_risk — $500K is a 5% problem at $10M ARR but a 0.5% problem at $100M ARR.
Including already-churned customers (realized loss, not risk) or netting expansion upside against the exposure.

customers.percent_arr_at_risk
customers.churn_risks
customers.top_customer_concentration
customers.net_revenue_retention
customers.gross_revenue_retention
sales.arr

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.