| name | early-churn-downgrade-signal-detection |
| version | 1.0.0 |
| deployment_target | plugin |
| status | PROPOSED |
| description | Three-tier churn signal model starting at deal close (not renewal). Tier 1 fires at close using configurable rule-mode thresholds (or cohort-mode correlations when 6+ months of data available). Tier 2 fires 30–90 days post-onboarding on behavioral signals. Tier 3 fires 90–120 days pre-renewal on late-stage risk. Every flag includes escalation path and owner. Triggers: 'churn signals', 'early churn', 'downgrade risk', 'at-risk accounts', 'churn detection', 'which accounts are at risk of churning'. |
[PROPOSED]
Early Churn / Downgrade Signal Detection
Moves churn detection upstream from renewal conversation to deal close.
The earlier the signal, the more runway to act.
Reference: Churn signal tiers → ../../../shared/revops-domain-model.md §8
Reference: Confidence bands → ../../../shared/revops-domain-model.md §2
Config reads: tier1_mode, discount_elevated_threshold_pct,
avg_sales_cycle_days, renewal_conversation_window_days, cs_platform_connected
Pre-flight
Read ~/.claude/plugins/config/claude-for-customer-success/rev-ops/CLAUDE.md and
~/.claude/plugins/config/claude-for-customer-success/company-profile.md.
If either is missing or contains [PLACEHOLDER] markers, stop and prompt for
/rev-ops:cold-start-interview.
Note from config: tier1_mode, discount_elevated_threshold_pct,
avg_sales_cycle_days, renewal_conversation_window_days, cs_platform_connected
G-code dependency: All G-code guardrails referenced in this skill (G1–G9) are defined in the CLAUDE.md config loaded above. If Pre-flight halts or config is missing, G-codes are undefined — do not proceed with partial config.
Use when
- Account shows structural signals suggesting churn or downgrade risk
- Tier 1 accounts need proactive churn signal monitoring
- Deal desk context brief requires churn signal assessment for a specific account
Do NOT use for
- Deal health scoring on pre-close pipeline (use deal-health-scoring)
- Outcome rubric level assessment (use deal-to-outcome-tracing)
- Revenue brief generation (this is a signal, not a brief)
Typical Activation
"Churn signal for [account]", "early churn detection", "downgrade risk", "Tier 1 churn signals", "flag at-risk accounts"
Reasoning Protocol
Before generating output, apply these primers:
-
CLASSIFY: What type of churn signal request is this?
- Single account assessment (one account — tier evaluation + active signals + recommended action)
- Portfolio scan (segment or full book — distribution by tier + top ACV accounts at risk)
- Tier 1 at deal close (structural signals at close — rule mode or cohort mode per company profile)
- Tier 2 behavioral (30–90 days post-onboarding — usage, OCV, champion, EBR signals)
- Tier 3 pre-renewal (90–120 days out — health trend, renewal conversation, support volume)
-
CONSTRAINTS: What limits the solution space?
- Confirm activation — user asking about churn risk, at-risk accounts, or downgrade signals
- Determine scope: single account or portfolio scan
- Check CS platform connector — health score, usage, renewal date required; declare fallback if absent
- Declare tier1_mode: rule or cohort [Company profile] — required on every Tier 1 output
- Apply G7 — every Tier 2 and Tier 3 flag must include escalation path and named owner
- Apply G5 — signals are analytical inputs; CS and CS manager own the response
- Apply G6 — data-as-of on all reads
-
EXPERT CHECK: What would a veteran CS operations analyst verify first?
- Is tier1_mode declared before presenting any Tier 1 output? Rule mode and cohort mode produce
different signal sets — presenting without declaring the mode obscures the basis for the flag.
- Is the CS platform data fresh enough to score Tier 2 and Tier 3? Stale health scores and
usage data produce misleading signals — declare data age before surfacing any tier flag.
- Does every Tier 2 and Tier 3 flag carry a named escalation owner? "Escalate to CS team"
is not an actionable path — the owner must be a named role or person, not a team alias.
- Is the scope confirmed before a portfolio scan? Large books may return partial data from
the CS platform — scope the scan and declare any data limits upfront.
-
ANTI-PATTERNS: Common mistakes to avoid:
- Presenting churn signals as directives rather than analytical inputs (G5 violation)
- Surfacing CS platform reads without data-as-of timestamp (G6 violation)
- Omitting escalation path or owner on any Tier 2 or Tier 3 flag (G7 violation)
- Running a Tier 1 assessment without declaring tier1_mode (rule vs. cohort)
After execution, verify:
- G5 qualifier present: signals are analytical inputs; CS owns the response
- G6 data-as-of label applied to all CS platform and CRM reads
- G7 escalation path with named owner present on every Tier 2 and Tier 3 flag
- Confidence: High when CS platform is connected and data is current; Moderate when data is stale or connector is unavailable
- Confidence: [High] when CS platform is connected and data is current / [Medium] when data is stale or connector is unavailable / [Low] if all inputs are manual or unverified
Three Tiers [revops-domain-model.md §8]
Tier 1 — Structural risk (at deal close)
Declare mode on every output:
[Tier 1: Rule mode — configurable thresholds] or
[Tier 1: Cohort mode — correlation-based]
Rule mode signals (defaults from company profile):
discount_pct > discount_elevated_threshold_pct
sales_cycle_days > avg_sales_cycle_days × tier1_long_cycle_multiplier
stakeholder_threads = 1 (single-threaded, if tier1_single_thread_flag = true)
ocv_entry_referenced = false (no Ratified OCV at close)
Cohort mode: Requires churn_cohort_data_path in company profile.
Compares deal attributes to historical closed/won-to-churn cohort.
Tier 2 — Behavioral risk (30–90 days post-onboarding)
usage_below_adoption_curve — product usage below expected for tier
ocv_rubric_stuck_at_L0 — past first checkpoint
champion_departure_detected — contact role change in CRM
ebr_qbr_rescheduled_twice — ≥2 reschedules logged
Tier 3 — Late-stage risk (90–120 days pre-renewal)
health_score_declining_trend — ≥3 consecutive weeks of decline
renewal_conversation_not_initiated — past standard window
support_ticket_spike — ticket volume >2x baseline
executive_sponsor_disengaged — no activity in [N] days
Output Formats
Single account:
CHURN SIGNAL ASSESSMENT — [Account Name]
[CRM ✓ live / CS Platform ✓ live — as of YYYY-MM-DD]
[Tier 1: Rule mode] [Confidence: High/Moderate]
ACV: $XXXk Segment: [segment] Days to renewal: [N]
Active signals:
Tier 1: [✓ / —] [Signal description if firing]
Tier 2: [✓ / —] [Signal description if firing]
Tier 3: [✓ / —] [Signal description if firing]
Highest active tier: [Tier N]
Recommended action: [Specific — not generic]
WHO: [CS manager / CSM / AE]
BY: [Timeframe]
[G7: Escalation path — [CS manager name/role] via [channel] within [timeframe]]
[G5: Signal is analytical input. CS owns the response.]
Portfolio scan:
CHURN SIGNAL SCAN — [Portfolio/Segment] — [Date]
[CS Platform ✓ live — as of YYYY-MM-DD] [Tier 1: Rule mode]
Tier 3 (pre-renewal, immediate action): [N] accounts $XXXk ARR at risk
Tier 2 (behavioral, near-term action): [N] accounts $XXXk ARR at risk
Tier 1 (structural, monitor): [N] accounts $XXXk ARR at risk
Top 5 highest-ACV accounts by risk tier:
[table]
[G7: Each flagged account requires named escalation path]
[G5: Signals are inputs. CS leadership owns the response plan.]
Reference Files
| File | Purpose |
|---|
references/reasoning-blueprint.md | Problem classification taxonomy, domain heuristics, common failure modes, and expert judgment patterns for this skill |
Security & Permissions
Network access: None direct — all external data access is mediated by host-provided MCP connector tools (HubSpot, CS platform, Slack, Linear). This skill makes no direct outbound HTTP calls.
Filesystem scope: None — this skill does not read or write local files. All data is provided at runtime via parameters or MCP connector responses.
Subprocess execution: None.
Dynamic code execution: None — pseudocode in this skill represents the logic contract and is not executed at runtime.
Data sensitivity: Inputs may contain confidential deal, customer, and revenue data. Handle with RevOps-level confidentiality.
Trust & Verification
Input trust model: All user-provided parameters are treated as untrusted at intake. Numeric inputs are validated for plausible range before use in calculations. String inputs are not evaluated as code.
Output trust model: All outputs are proposals or analytical inputs — no outputs constitute approved decisions, revenue commitments, or system actions without explicit human confirmation.
Connector data: Data retrieved via MCP connectors is treated as read-only observed state. Timestamps and data-as-of labels are applied to all connector-sourced values per G6.
Write-tier confirmation: Any proposed write to HubSpot, Linear, or Slack is surfaced as a draft requiring explicit user confirmation before execution.
Guardrails
- G7: Every Tier 2 and Tier 3 flag requires escalation path and owner — no exceptions
- G5: Signals are inputs; rep and manager own judgment
- G6: Data-as-of required on all reads
- Cross-plugin: Tier 3 flags → suggest using the CSM plugin's risk-flag skill (if the
csm plugin is installed, run /csm:risk-flag) and the Renewals plugin's renewal-prep skill (if the renewals plugin is installed, run /renewals:renewal-prep)
