| name | account-expansion-signal-design |
| description | Design the signal set and mart model for an account expansion-readiness view alongside the churn-risk tier — identifying which signals predict expansion, how to surface them without confusing the CS team, and what mart additions are needed. Reach for this skill when a CS team wants both a churn-risk view and an expansion-opportunity view from the same health mart. |
Skill: Account Expansion Signal Design
A health tier focused only on churn risk surfaces who is in trouble. A complete CS analytics build also surfaces who is primed for a grow motion — expansion-ready accounts with high usage momentum, champion depth, and positive sentiment. This skill designs the expansion signal layer alongside the existing risk tier without conflating the two.
The core rule: separate expansion from churn mitigation
Expansion signals and churn-risk signals are different animals:
| Signal type | Churn risk | Expansion readiness |
|---|
| Usage trend | Down trend = risk | Up trend = expansion candidate |
| Health score | Declining = risk | High + stable = expansion candidate |
| Champion depth | Single champion = risk | Multiple active champions = expansion ready |
| Support load | High escalations = risk | Low support + resolved backlog = expansion ready |
| NPS | Low + declining = risk | High + recent = expansion ready |
Do not fold expansion signals into the churn-risk tier or use a single "health score" that conflates the two. A "healthy" account in the churn-risk tier is not necessarily expansion-ready. Keep the tiers and the views separate.
Step 1 — Define the expansion outcome
Pick the one outcome the expansion signal predicts:
- Upsell — account upgrades to a higher plan tier
- Cross-sell — account adds a new product line
- Seat expansion — account grows user count within the current plan
- Composite expansion — any revenue-expansion event (fallback when the above are not distinguishable in source data)
Step 2 — Select the expansion signals (4-6 max)
Domain-neutral expansion signal categories:
| Category | Example signals | Grain + window |
|---|
| Usage momentum | Active-user count trending up 30-day rolling; feature adoption rate above baseline | Account, 30-day |
| Champion depth | Count of named active users; count of departments with active usage | Account, rolling 90-day |
| Engagement quality | QBR attended; product-feedback submitted; champion-to-new-stakeholder introductions | Account, event-based |
| Sentiment | NPS >= 8 in last 180 days; last CSAT > 4/5 | Account, last response |
| Renewal runway | Days since last renewal > 180 (enough runway to execute a grow motion) | Account, point-in-time |
| Feature depth | Count of distinct features used in last 30 days above adoption baseline | Account, 30-day |
All six signals are leading for expansion — they fire before the expansion event. Verify each against historical upsell/cross-sell outcomes the same way churn signals are validated.
Step 3 — Define the expansion tier rule
Expansion Ready := usage_trend_30d = up
AND champion_depth >= 2
AND (nps_last_180d >= 8 OR csat_last_90d >= 4)
AND renewal_runway_days > 180
Expansion Watch := one or two signals above threshold but not all three
(monitor — not yet ready for a grow motion)
Neutral := everything else
The expansion tier runs alongside the churn-risk tier. An account can be Red (churn risk) and Neutral (no expansion signal) at the same time. Render them as two separate columns or two separate views — not a single composite.
Step 4 — Mart additions required
This skill produces a domain-layer contract for data-platform:
Hand the build to data-platform/etl-pipeline-engineer and database-setup-guide. This plugin specifies the contract; data-platform builds it.
Step 5 — Explainability for expansion-ready accounts
Apply the same explainability contract as the churn-risk tier: every Expansion-Ready account shows its 2-3 driving signals in the CS surface. The CS rep opening an account marked Expansion-Ready must be able to see why in under 30 seconds.
Pitfalls
- Folding expansion signals into the churn-risk tier — a single composite obscures both signals and produces a tier the CS team can't explain.
- Using lagging signals (signed contract expansion, invoice uplift) as expansion predictors — they confirm an expansion that already happened.
- Building the expansion view before the churn-risk tier is validated — fix the baseline view before adding growth complexity.
- Missing the renewal-runway signal: an expansion motion requires enough contract runway to execute; a renewal that is 30 days out is not expansion-ready regardless of usage.
See also
