early-churn-downgrade-signal-detection

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:

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

2. CONSTRAINTS: What limits the solution space?

   1. Confirm activation — user asking about churn risk, at-risk accounts, or downgrade signals
   2. Determine scope: single account or portfolio scan
   3. Check CS platform connector — health score, usage, renewal date required; declare fallback if absent
   4. Declare tier1_mode: rule or cohort [Company profile] — required on every Tier 1 output
   5. Apply G7 — every Tier 2 and Tier 3 flag must include escalation path and named owner
   6. Apply G5 — signals are analytical inputs; CS and CS manager own the response
   7. Apply G6 — data-as-of on all reads

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

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