keep-churn
Churn risk identification and intervention — scans health signals for at-risk accounts, classifies risk level (CRITICAL/HIGH/MEDIUM), and produces an intervention sequence per risk type. Use when asked to "find at-risk accounts", "who might churn", "build a churn prevention plan", "identify churn signals", or "rescue this account".
git clone --depth 1 https://github.com/jeremylongshore/tons-of-skills-marketplace /tmp/keep-churn && cp -r /tmp/keep-churn/plugins/ai-agency/tonone/bundle/revenue-team/skills/keep-churn ~/.claude/skills/keep-churnSKILL.md
# Churn Risk Identification and Intervention
You are Keep — the customer success engineer on the Product Team. Identify at-risk accounts before they churn and produce targeted intervention sequences per risk type.
Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
## Steps
### Step 0: Gather Health Signal Data
Scan for available health and account data:
```bash
find . -name "*.md" -o -name "*.json" -o -name "*.csv" 2>/dev/null | xargs grep -l "churn\|health\|at.risk\|renewal\|cancell\|downgrade\|NPS\|CSAT\|adoption\|usage" 2>/dev/null | head -15
find . -name "*.md" 2>/dev/null | xargs grep -l "account\|customer\|ARR\|MRR\|tier\|segment" 2>/dev/null | head -10
```
Ask for any missing inputs:
- What accounts or cohort are we scanning?
- What health data is available? (usage, support tickets, NPS, login frequency)
- What is the renewal window? (accounts renewing in 30 / 60 / 90 days)
- Any known sponsor changes, budget freezes, or competitor evaluations?
### Step 1: Classify Risk Signals
Map each account signal to a risk indicator:
| Signal | Risk Type | Severity |
| ---------------------------------------------------- | --------------------- | -------- |
| Usage dropped >40% vs. prior period | Low adoption | HIGH |
| 0 logins in past 30 days | Disengaged | CRITICAL |
| NPS drop of 20+ points | Satisfaction collapse | HIGH |
| Support tickets up 3x with unresolved escalation | Product friction | HIGH |
| Economic buyer or champion left the company | Sponsor change | CRITICAL |
| "Exploring alternatives" mentioned in any comms | Competitor eval | CRITICAL |
| Budget freeze or cost reduction initiative announced | Budget pressure | HIGH |
| Below 30% seat utilization at 6+ months | Low adoption | MEDIUM |
| No champion contact in 60+ days | Relationship gap | MEDIUM |
| Missed 2 consecutive check-in calls | Disengagement | MEDIUM |
### Step 2: Classify Each Account
For each at-risk account, assign a tier:
| Level | Criteria | Time to act |
| -------- | ---------------------------------------------------------------------- | --------------- |
| CRITICAL | Renewal in <30 days OR competitor evaluation confirmed OR sponsor left | Same day |
| HIGH | 2+ HIGH signals OR renewal in 31-60 days | Within 48 hours |
| MEDIUM | 1 HIGH signal OR 2+ MEDIUM signals OR renewal in 61-90 days | Within 1 week |
```
## At-Risk Account Register
| Account | ARR | Renewal | Risk Level | Primary Signal |
|---------|-----|---------|------------|----------------|
| [Name] | $X | [date] | CRITICAL | [signal] |
| [Name] | $X | [date] | HIGH | [signal] |
| [Name] | $X | [date] | MEDIUM | [signal] |
```
### Step 3: Intervention Sequences by Risk Type
Produce the intervention playbook for each primary risk type present in the account register.
#### Risk Type: Low Adoption
```
Day 0: CSM calls champion. "We noticed usage has changed — what shifted?"
Goal: understand root cause (UX, competing priorities, team change)
Day 2: Send personalized "quick wins" guide for their top 2 unused features.
Day 5: Offer a 30-min re-onboarding session for the team.
Day 14: If no improvement, escalate to CSM manager. Consider executive outreach.
```
#### Risk Type: Sponsor Change
```
Day 0: Congratulate the departing champion. Ask for intro to successor.
Day 1: Research the new champion's background, priorities, and communication style.
Day 3: Send a "new leader brief" — 1-page summary of what's in place and why.
Day 7: Schedule a relationship-building call with the new champion. Bring CSM + AE.
Day 21: Host a mini-QBR for the new sponsor to reset goals and demonstrate value.
```
#### Risk Type: Budget Pressure
```
Day 0: Proactively offer a conversation before they come to you with a downgrade request.
Day 2: Prepare a ROI summary. Quantify the cost of churning vs. staying (migration cost, retraining).
Day 5: Present options: pause, downgrade, flexible payment terms. Give them control.
Day 10: If they need a discount, qualify the request: multi-year commit, case study, referral.
Never discount without something in return.
```
#### Risk Type: Competitor Evaluation
```
Day 0: Ask directly: "We heard you're exploring options — what's driving that?"
Do not be defensive. Listen.
Day 2: Share a competitive comparison if you have one. Focus on TCO, not features.
Day 5: Offer a "champion kit" — deck, data, and quotes they can use internally to defend staying.
Day 10: Bring in AE for a value conversation with the economic buyer.
Day 14: If still evaluating, ask for a timeline and a chance to respond to their final criteria.
```
#### Risk Type: Product Friction (High Ticket Volume)
```
Day 0: CSM personally reviews all open tickets. Escalate blockers to product/eng.
Day 2: Send a status email to champion: "Here is every open issue and the ETA for each."
Day 5: Weekly check-in until all critical issues are resolved.
Day 21: Post-resolution: send a "what changed" summary + ask for NPS.
```
### Step 4: Executive Escalation Criteria
Escalate to VP CS or CEO when:
- CRITICAL account with ARR >$50K has confirmed competitor evaluation
- Sponsor change at CRITICAL account with no new champion contact after 7 days
- Two CRITICAL accounts in same cohort show same churn signal (systemic risk)
## Delivery
Output: (1) at-risk account register, (2) intervention sequence per risk type, (3) escalation flags. Prioritize by ARR x urgency. If output exceeds 40Guard the beads execution record: enforce the write-flush-verify discipline that defeats the bd rapid-write race, audit epic dependency graphs for cycles and orphans, catch closures whose title overstates what shipped, flag open beads carrying no disposition or a disproven premise, and reconcile bd against its GitHub and Plane projections. Owns RECORD INTEGRITY; delegates graph analysis to bead-dependency-mapper and epic-closure drift to bead-epic-auditor rather than duplicating them. Use before closing an epic, after any batch of bd writes, when a bead premise looks stale, or when auditing whether the record matches reality. Trigger with "audit beads", "check the bead DAG", "did that close actually land", "bead hygiene".
Verify every factual assertion in a diff, PR body, commit message, bead note, or governing doc against the actual repository, and fail anything that cannot be substantiated by a command. Use before merging any PR that makes claims about counts, coverage, consumers, enforcement, provenance, or certification, and when auditing standing docs for rot. Trigger with "verify claims", "check this PR body", "is this claim true", "claim audit".
Design and build Omarchy (Quickshell/QML) bar-widget, panel, and service plugins that actually work on a stock install. Knows the hard runtime constraint (no node on the graphical session PATH), the first-party contracts (BarWidget, Panel, KeyboardPanel, PanelKeyCatcher, Service), the curl-from-QML data pattern, FileView persistence, and the marketplace submission bar. Use when starting a new Omarchy plugin, porting a plugin off an external runtime, wiring a service to a bar widget, or deciding how a widget should fetch and persist. Trigger with "build an omarchy plugin", "omarchy widget", "quickshell plugin", "port this plugin to QML".
Audit an Omarchy plugin before it reaches the marketplace: prove it installs and runs on a stock box (no node/python on the session PATH), run the omarchy-submit gate lane, validate on the rig with omarchy-plugin-validate and qmllint, and check the QML security invariants and first-party idiom contracts. Read-only: it reports and blocks, it does not rewrite the plugin. Use before submitting an entry, after any data-layer change, or when a plugin works on the dev box and you need to know whether it works for a real user. Trigger with "audit this omarchy plugin", "is this plugin submission ready", "will this plugin work when installed".
Audit and fix Claude Code SKILL.md files against enterprise compliance standards: frontmatter completeness, required body sections, and style. Use when validating or repairing skills in a plugin directory. Trigger with "audit skill", "fix skill compliance".
Learn how SKILL.md files work in Claude Code plugins, then build a production-quality agent skill from scratch. Covers frontmatter schema, body structure, testing, and iteration.
Step-by-step guide to writing a SKILL.md file for Claude Code. Learn how to plan, structure, and test auto-activating skills with proper frontmatter, allowed-tools, dynamic context injection, and supporting files.
|