claude-code-arcane 1.0.0

package/skills/create-stories/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: create-stories
+description: "Break an epic into implementable story files with acceptance criteria, GDD traceability and ADR guidance. Run after /create-epics."
+category: "agile"
+argument-hint: "[epic-slug | epic-path] [--review full|lean|solo]"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Write, Task, AskUserQuestion
+agent: lead-programmer
+---
+# Create Stories
+
+Break an epic into implementable stories — one behavior per story, ~2-4h each, fully traceable to GDD requirement + ADR decision. Run per epic, Foundation first, then Core, etc.
+
+Output: `production/epics/[epic-slug]/story-NNN-[slug].md`
+
+## 1. Parse Argument
+
+Resolve review mode: `--review` arg → `production/review-mode.txt` → default `full`. Accept epic-slug or full path. No arg → list available epics via Glob.
+
+## 2. Load Everything
+
+Read in full: EPIC.md, its GDD (all 8 sections), all governing ADRs (Decision, Implementation Guidelines, Engine Compatibility, Engine Notes), `control-manifest.md` (rules + manifest version), `tr-registry.yaml`.
+
+**ADR existence validation:** confirm all referenced ADR files exist on disk. Missing → stop immediately, redirect to `/architecture-decision`.
+
+## 3. Classify Stories by Type
+
+| Type | Assign when criteria reference... |
+|---|---|
+| **Logic** | Formulas, thresholds, state transitions, calculations |
+| **Integration** | Two+ systems interacting, signals crossing boundaries, save/load |
+| **Visual/Feel** | Animation, VFX, timing, audio sync |
+| **UI** | Menus, HUD, buttons, screens, tooltips |
+| **Config/Data** | Balance tuning values, data files only |
+
+Mixed → assign type with highest implementation risk. Type determines test evidence required at `/story-done`.
+
+## 4. Decompose GDD into Stories
+
+For each GDD AC: group related criteria → each group = one story. Order: foundational first, edge cases last, UI last. Per story determine: GDD requirement + TR-ID (from registry), governing ADR (Proposed → story Blocked), story type, engine risk.
+
+### 4b. QA Lead Gate (full mode only)
+
+Solo/lean → skip. Full → spawn `qa-lead` gate QL-STORY-READY with story list + ACs + types + TR-IDs. Revise until ADEQUATE. Then qa-lead produces test case specs per story:
+
+- **Logic/Integration:** Given/When/Then + edge cases per AC
+- **Visual/UI:** Setup/Verify/Pass condition per AC
+
+Specs embed into each story's `## QA Test Cases` section.
+
+## 5. Present Stories for Review
+
+Show full story list (title, type, ADR, TR-IDs covered, test required) before writing. AskUserQuestion: write all / review first.
+
+## 6. Write Story Files
+
+Each story file includes: header (epic, status, layer, type, manifest version), context (GDD path, TR-ID, ADR + decision summary, engine risk + notes, manifest rules), acceptance criteria (from GDD), implementation notes (from ADR), out of scope, QA test cases (from qa-lead), test evidence (required path by type + status), dependencies (depends on / unlocks).
+
+Also update EPIC.md with populated stories table.
+
+### 4b. Producer Epic Gate (full mode only)
+
+Solo/lean → skip. Full → spawn `producer` gate PR-EPIC before writing.
+
+## 7. After Writing
+
+AskUserQuestion with context-aware next steps: start implementing (`/story-readiness`), create stories for next epic, plan sprint, or stop.
+
+## Protocol
+
+- Read all inputs before presenting
+- Present all stories at once, not one at a time
+- Warn on blocked stories (Proposed ADR)
+- Ask before writing (per-epic approval)
+- All content from GDDs, ADRs, manifest — no invention
+- Never start implementation — stops at story file level
+
+## Checklist
+
+- [ ] Every story traces back to its parent epic via epic-slug reference
+- [ ] Each story has a classified type (Logic, Integration, Visual/Feel, UI, Config/Data)
+- [ ] Acceptance criteria are defined with Given/When/Then format for every story
+- [ ] No single story exceeds one sprint of estimated effort (~2-4h target)
+- [ ] Stories with Proposed ADRs are marked as Blocked
+- [ ] EPIC.md stories table is updated with all created stories

package/skills/create-test-user/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: create-test-user
+description: "Crea un usuario de prueba en el proyecto: anónimo, autenticado o admin. Usa seed scripts, endpoints de admin, o inserts directos."
+category: "testing"
+argument-hint: "[user-type: anonymous | student | admin]"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# Skill: create-test-user
+
+## Trigger
+When the user says "create test user", "crear usuario de prueba", "test user", or similar.
+
+## Workflow
+
+1. Ask what type of user is needed:
+   - Anonymous (no auth)
+   - Authenticated student
+   - Admin / instructor
+
+2. Check the project for existing seed scripts or user creation endpoints:
+   - Look in `db/seeds/`, `db/local/`, or test fixtures
+   - Check for admin API endpoints
+   - Check for database insert scripts
+
+3. Create the user using the appropriate method:
+   - Direct database insert
+   - API endpoint call
+   - Seed script execution
+
+4. Return the user credentials and any relevant tokens
+
+## Notes
+- Never create users in production databases
+- Use clearly identifiable test data (e.g., email: test@example.com)
+- Document any test users created so they can be cleaned up later

package/skills/create-ticket/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: create-ticket
+description: "Conversational Jira ticket creation: gather title, description, AC, priority via dialog, create via API and return URL."
+category: "agile"
+argument-hint: "[project-key] [title]"
+user-invocable: true
+allowed-tools: Read, Bash
+---
+
+# Skill: create-ticket
+
+## Trigger
+
+When the user says "create ticket", "nuevo ticket", "crear ticket", or similar.
+
+## Workflow
+
+1. Ask the user for:
+   - **Title**: short description of the task
+   - **Description**: what needs to be done (functional requirements)
+   - **Acceptance criteria**: how do we know it's done?
+   - **Priority**: if not provided, default to Medium
+   - **Type**: Bug, Story, Task (if not provided, infer from description)
+
+2. If the user provides incomplete info, ask follow-up questions about:
+   - Scope: what's included and what's NOT included
+   - Edge cases: what should happen in unusual scenarios
+   - Testing requirements: how should this be tested
+
+3. Create the ticket in Jira using the credentials from `~/.config/jira/credentials`:
+   - Use the project key from context or ask the user (default options: ALZ, TICH, TUNI, VIA)
+   - Format the description in Jira markdown
+   - Include acceptance criteria as a checklist
+   - Use `curl` against `$JIRA_BASE_URL/rest/api/3/issue` (see `/jira-tickets` for full payload reference)
+
+4. Return the ticket URL to the user: `https://aula-educabot.atlassian.net/browse/{KEY}-{NUM}`
+
+## Notes
+
+- Always write tickets in Spanish (the team's working language)
+- Keep titles concise (under 80 characters)
+- Separate functional requirements from technical requirements
+- Technical enrichment happens AFTER ticket creation, not during
+- For bulk creation, search, transitions, or sprint reports use `/jira-tickets` instead
+
+## Recommended Next
+
+After ticket creation:
+- `/jira-tickets transition <KEY-NUM>` to move it through the workflow
+- `/jira-tickets search` to find related tickets

package/skills/cro-advisor/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: cro-advisor
+description: "Revenue leadership for B2B SaaS companies. Revenue forecasting, sales model design, pricing strategy, net revenue retention, and sales team scaling."
+argument-hint: ""
+category: "clevel-advisors"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# CRO Advisor
+
+Revenue frameworks for building predictable, scalable revenue engines — from $1M ARR to $100M and beyond.
+
+## Core Responsibilities
+
+| Area | What the CRO Owns | Reference |
+|------|------------------|-----------|
+| **Revenue Forecasting** | Pipeline model, scenario planning, board forecast | `references/sales_playbook.md` |
+| **Sales Model** | PLG vs. sales-led vs. hybrid, team structure | `references/sales_playbook.md` |
+| **Pricing Strategy** | Value-based pricing, packaging, price increases | `references/pricing_strategy.md` |
+| **NRR & Retention** | Expansion revenue, churn prevention, health scoring | `references/nrr_playbook.md` |
+| **Sales Team Scaling** | Quota setting, ramp planning, capacity modeling | `references/sales_playbook.md` |
+
+## Diagnostic Questions
+
+**Revenue Health:**
+- What's your NRR? Below 100% means everything else is a leaky bucket.
+- What percentage of ARR comes from expansion vs. new logo?
+
+**Pipeline & Forecasting:**
+- Pipeline coverage ratio (pipeline / quota)? Under 3x is a problem.
+- Stage-by-stage conversion rate? Where do deals die?
+
+**Pricing:**
+- If fewer than 20% of prospects push back on price, you're underpriced.
+
+## Revenue Metrics
+
+| Metric | Target | Red Flag |
+|--------|--------|----------|
+| ARR Growth YoY | 2x+ at early stage | Decelerating 2+ quarters |
+| NRR | > 110% | < 100% |
+| GRR (gross retention) | > 85% annual | < 80% |
+| Pipeline Coverage | 3x+ quota | < 2x entering quarter |
+| Magic Number | > 0.75 | < 0.5 |
+| Quota Attainment % | 60-70% of reps | < 50% |
+
+**Revenue Waterfall:** Opening ARR + New Logo + Expansion - Contraction - Churn = Closing ARR
+
+## Red Flags
+
+- NRR declining two quarters in a row — customer value story is broken
+- Pipeline coverage below 3x entering the quarter — already forecasting a miss
+- < 50% of sales team quota-attaining — comp plan, ramp, or quota calibration issue
+- Magic Number below 0.5 — sales spend not converting to revenue
+- Single customer > 15% of ARR — concentration risk
+
+## Integration with Other C-Suite Roles
+
+| When... | CRO works with... | To... |
+|---------|------------------|-------|
+| Pricing changes | CPO + CFO | Align value positioning, model margin impact |
+| Headcount plan | CFO + CHRO | Justify sales hiring with capacity model |
+| NRR declining | CPO + COO | Root cause: product gaps or CS process failures |
+| Pipeline SLA | CMO | MQL → SQL conversion, CAC by channel |
+
+## Proactive Triggers
+
+- NRR < 100% → leaky bucket, retention must be fixed before pouring more in
+- Pipeline coverage < 3x → forecast at risk, flag to CEO immediately
+- Top customer concentration > 20% ARR → single-point-of-failure revenue risk
+
+## Reasoning Technique: Chain of Thought
+
+Pipeline math must be explicit: leads → MQLs → SQLs → opportunities → closed. Show conversion rates at each stage.
+
+## Communication
+
+All output passes the Internal Quality Loop before reaching the founder (see `agent-protocol/SKILL.md`).
+- Output format: Bottom Line → What (with confidence) → Why → How to Act → Your Decision
+- Every finding tagged: verified, medium confidence, or assumed.
+
+## Resources
+- `references/sales_playbook.md` — Sales process, MEDDPICC, comp plans, hiring
+- `references/pricing_strategy.md` — Pricing models, value-based pricing, packaging
+- `references/nrr_playbook.md` — NRR deep dive, churn anatomy, health scoring, expansion

package/skills/cro-advisor/references/nrr_playbook.md

@@ -0,0 +1,380 @@
+# NRR Playbook
+
+Net Revenue Retention is the single most important metric for a SaaS company's health and valuation. A company with 120% NRR grows even if it closes zero new deals. A company with 80% NRR is filling a bucket with a hole in it.
+
+---
+
+## NRR Deep Dive
+
+### The Fundamental Formula
+
+```
+NRR = (Opening MRR + Expansion MRR - Contraction MRR - Churned MRR) / Opening MRR
+
+Example:
+  Opening MRR:     $1,000,000
+  Expansion:       +$150,000
+  Contraction:     -$30,000
+  Churn:           -$80,000
+  Closing MRR:     $1,040,000
+  NRR = $1,040,000 / $1,000,000 = 104%
+```
+
+### NRR vs. GRR
+
+| Metric | Formula | What It Tells You |
+|--------|---------|------------------|
+| **GRR** | (Opening - Contraction - Churn) / Opening | Retention floor — how much you keep without any expansion |
+| **NRR** | (Opening + Expansion - Contraction - Churn) / Opening | Net health — expansion offsetting churn |
+| **Logo Retention** | (Customers start - Customers churned) / Customers start | Volume retention, ignores revenue weight |
+
+**GRR is the floor. NRR is the ceiling.**
+
+If GRR is 80% and NRR is 105%, your expansion is covering 25 points of churn. That's fragile — any expansion slowdown turns NRR negative. The fix is GRR, not more upsell.
+
+### Benchmarks by Segment
+
+| Segment | Good GRR | Good NRR | Exceptional NRR |
+|---------|---------|---------|----------------|
+| SMB-focused | 80-85% | 95-105% | > 110% |
+| Mid-Market | 85-90% | 105-115% | > 120% |
+| Enterprise | 90-95% | 115-130% | > 140% |
+
+Enterprise NRR can exceed 140% because large accounts expand substantially and rarely churn entirely — they may downgrade but full logo churn is rare if the product is embedded.
+
+### NRR by Cohort
+
+Don't just measure NRR across the full base — measure it by customer cohort (month of acquisition).
+
+```
+Jan 2024 Cohort:
+  Opening MRR (Jan 2024):  $50,000
+  MRR at Jan 2025:         $62,000
+  12-month NRR:             124%
+
+Feb 2024 Cohort:
+  Opening MRR (Feb 2024):  $45,000
+  MRR at Feb 2025:         $38,000
+  12-month NRR:             84%  ← problem cohort
+```
+
+Cohort analysis reveals:
+- Whether a specific acquisition channel brings lower-quality customers
+- Whether a product change or pricing shift affected retention
+- Whether specific sales reps or time periods created bad-fit deals
+
+---
+
+## Churn Anatomy
+
+Not all churn is equal. Know the breakdown before prescribing solutions.
+
+### Churn Types
+
+| Type | Definition | Primary Cause | Fix |
+|------|-----------|--------------|-----|
+| **Logo churn** | Customer cancels entirely | No value, poor fit, champion left, competitor | Root cause analysis, ICP tightening |
+| **Revenue churn** | ARR lost (cancels + downgrades combined) | Same as logo + downgrade triggers | Address both volume and revenue |
+| **Involuntary churn** | Failed payment, expired card | Billing friction | Dunning improvement (quick win: 20-30% recovery) |
+| **Voluntary churn** | Active cancellation decision | Explicit dissatisfaction, competitor win | Exit interview + intervention program |
+| **Contraction** | Downgrade, seat reduction | Overpurchased, budget cut, team reduction | Right-sizing program, annual contracts |
+
+### Churn Root Cause Framework
+
+Run this analysis quarterly on all churned accounts:
+
+**Step 1: Categorize by reason**
+- No value realized (never activated or adopted)
+- Value realized but budget cut (external, not product)
+- Switched to competitor (why? what did they offer?)
+- Champion left company (relationship loss, not product failure)
+- Company shutdown / acquisition (unavoidable)
+
+**Step 2: Look for patterns**
+- Which ICP signals predict churn? (company size, vertical, acquisition channel)
+- Which product behaviors predict churn? (no login in 30 days, never completed onboarding)
+- Which time periods have highest churn? (months 3, 6, 12 are typical cliff points)
+
+**Step 3: Act on the patterns**
+- ICP pattern → tighten qualification criteria
+- Behavior pattern → build early warning health score
+- Time cliff → build intervention playbooks for months 2, 5, 11
+
+### Exit Interview Protocol
+
+Talk to every churned customer if ACV > $10K. For smaller, do quarterly batch surveys.
+
+Questions:
+1. "What was the primary reason for your decision to cancel?"
+2. "What would have needed to be true for you to stay?"
+3. "What did you switch to, and what drove that decision?"
+4. "Was there a specific moment when you decided to leave?"
+
+Rules:
+- CSM who owned the account should NOT conduct the exit interview (too much relationship bias)
+- Use a neutral party or the VP CS
+- Document verbatim, not paraphrased
+- Feed patterns back to Product and Sales monthly
+
+---
+
+## Customer Health Scoring
+
+A health score predicts churn 60-90 days before it happens. Without one, you're reactive.
+
+### Health Score Components
+
+Score each account 0-100 across weighted signals:
+
+| Signal | Weight | Red (0-33) | Yellow (34-66) | Green (67-100) |
+|--------|--------|-----------|---------------|---------------|
+| **Product usage** (DAU/WAU, feature adoption depth) | 35% | < 20% seats active | 20-60% seats active | > 60% seats active |
+| **Engagement** (QBR attendance, champion responsiveness) | 20% | No response 60+ days | 30-60 days | Active, < 30 days |
+| **NPS / CSAT** | 20% | Score < 6 | Score 6-7 | Score 8-10 |
+| **Support volume** (negative signal: high volume = friction) | 15% | > 10 tickets/month | 3-10/month | < 3/month |
+| **Contract signals** (time to renewal, expansion in motion) | 10% | < 60 days to renewal, no expansion discussion | 60-90 days, passive | > 90 days, expansion active |
+
+**Composite score:**
+- 70-100: Healthy. Renewal confident. Identify expansion opportunity.
+- 50-69: At-risk. CSM check-in required. Executive sponsor loop-in if < 60 days to renewal.
+- 0-49: Red alert. Immediate intervention. VP CS or CEO call if strategic account.
+
+### Health Score Automation
+
+Trigger alerts automatically:
+```
+Score drops > 20 points in 30 days → CSM immediate outreach (same day)
+No product login in 14 days → Automated email + CSM flag (within 24 hours)
+Champion leaves company → Executive outreach (within 24 hours)
+Support escalation → CSM loop-in (within 2 hours)
+Renewal < 90 days + score < 60 → VP CS review (weekly)
+Seat utilization < 30% → Adoption intervention playbook triggered
+```
+
+### Leading Indicators vs. Lagging Indicators
+
+| Leading (predict future churn) | Lagging (confirm past churn) |
+|-------------------------------|------------------------------|
+| Login frequency declining | Cancellation submitted |
+| Feature adoption stalling at basic level | Non-renewal at contract end |
+| NPS score trend (not just snapshot) | Downgrade executed |
+| No QBR scheduled in 90+ days | Champion departure |
+| Support escalations increasing | Competitor mentioned in support |
+
+Build your health score from leading indicators. Lagging indicators tell you what already happened.
+
+---
+
+## Expansion Revenue Strategies
+
+Expansion is cheaper than acquisition. CAC for expansion is typically 20-30% of new logo CAC.
+
+### Expansion Motion 1: Seat Expansion
+
+**Trigger signals:**
+- Usage by unlicensed users (shared logins, "can you add my colleague?")
+- Team growth visible on LinkedIn (company hiring in target department)
+- Champion promotes to a new role with bigger team
+- Power users at license limit consistently
+
+**Playbook:**
+1. Pull monthly usage report showing which features unlicensed users are using
+2. Frame as: "Your team is getting value from X — you could be capturing that for the full team"
+3. Offer a team expansion proposal at renewal + 10% volume discount for seat adds
+4. Never penalize users for sharing logins before the conversation — that's a data asset
+
+### Expansion Motion 2: Upsell (Tier Upgrade)
+
+**Trigger signals:**
+- Customer consistently hitting usage/feature limits
+- Security or compliance requirement that requires higher tier
+- New stakeholder joining who needs admin controls
+- API usage growing rapidly (engineering team engagement)
+
+**Playbook:**
+1. Build a "value realized" report before the upsell conversation (ROI proof)
+2. Use QBR as the venue: "You've achieved X. Here's what's possible at the next level."
+3. Frame the upgrade as unlocking more of what's already working
+4. Time to renewal: start upsell conversation 90-120 days before renewal
+
+### Expansion Motion 3: Cross-sell
+
+**Trigger signals:**
+- Strategic account with adjacent problem your product can solve
+- New product launch that complements existing usage
+- Customer explicitly asks about a capability in your roadmap or adjacent product
+
+**Playbook:**
+1. Land with core product; build relationship and prove value
+2. Cross-sell only after health score is green and NPS > 7
+3. Introduce the new product through a champion, not a cold pitch
+4. Pilot pricing: bundle into renewal at modest uplift vs. separate sale
+5. Cross-sell owner: CSM or AE (define explicitly — joint ownership = no ownership)
+
+### Expansion Sequencing
+
+Don't try all three simultaneously. Sequence matters:
+
+```
+Month 0-3:   Activation focus — ensure core value delivered
+Month 3-6:   Seat expansion — grow usage within existing team
+Month 6-9:   Upsell conversation — unlock advanced features
+Month 9-12:  Cross-sell OR renewal + multi-year lock-in
+```
+
+### NRR Modeling
+
+Target breakdown for 115% NRR:
+
+```
+GRR:                  88% (12% lost to churn/contraction)
+Expansion rate:       27% (upsell + cross-sell + seat expansion)
+NRR:                  88% + 27% = 115%
+
+To reach 120% NRR:
+  Option A: Improve GRR to 92% (reduce churn), keep expansion at 28%
+  Option B: Keep GRR at 88%, improve expansion to 32%
+  Option C: Both, incrementally
+
+Option A is usually easier and more durable. Fix the hole first.
+```
+
+---
+
+## Customer Success Integration
+
+CS and Revenue are not separate functions. NRR lives at their intersection.
+
+### CS Team Structure (aligned to NRR)
+
+| CS Model | When to Use | NRR Focus |
+|----------|------------|-----------|
+| **High-touch CSM** | ACV > $25K | Named accounts, QBRs, executive relationships |
+| **Tech-touch / pooled** | ACV $5K-25K | Automated health scoring, office hours, community |
+| **Self-serve** | ACV < $5K | In-app guidance, knowledge base, email sequences |
+
+**CSM coverage ratios:**
+- High-touch: 1 CSM per $2M-4M ARR managed
+- Tech-touch: 1 CSM per $5M-10M ARR managed
+- Self-serve: Product and automation (no dedicated CSM)
+
+### CS Compensation (aligned to NRR)
+
+Don't pay CSMs a flat salary — align incentive to retention and expansion:
+
+```
+CS compensation structure:
+  Base: 70% of OTE
+  Variable: 30% of OTE
+
+Variable tied to:
+  GRR / NRR vs. target (50% of variable)
+  Health score improvement (25% of variable)
+  Expansion ARR facilitated (25% of variable)
+
+Do NOT pay CS commission on expansion ARR the same way AEs earn it.
+This creates conflict: CS will push expansion before the customer is ready.
+Instead, bonus for expansion milestones — it's a different incentive structure.
+```
+
+### QBR (Quarterly Business Review) Framework
+
+QBRs are the primary vehicle for expansion and churn prevention in enterprise accounts.
+
+**QBR agenda (60-90 minutes):**
+1. **Their goals, our progress** — review what they said success looked like at kickoff (10 min)
+2. **Usage and adoption data** — product metrics presented in business language, not feature language (15 min)
+3. **Value delivered** — ROI proof: time saved, revenue influenced, risk reduced (10 min)
+4. **Challenges and blockers** — what's preventing more adoption? (10 min)
+5. **Roadmap preview** — upcoming features relevant to their use case (10 min)
+6. **Next 90 days** — joint success plan with owner and due dates (10 min)
+7. **Expansion opportunity** — if health score is green and timing is right (10 min)
+
+**QBR anti-patterns:**
+- Leading with your product roadmap (they don't care; start with their results)
+- Bringing too many people from your side without matching seniority
+- Presenting at a VP without bringing the economic buyer
+- Skipping QBRs for "healthy" accounts (health can change fast)
+- No confirmed next step at the end
+
+---
+
+## Cohort-Based Retention Analysis
+
+Aggregate NRR hides the signal. Cohort analysis reveals it.
+
+### Retention Curve Analysis
+
+Plot retention by months since acquisition for each quarterly cohort:
+
+```
+Month 0:  100% (starting revenue)
+Month 3:  First cliff — early adopters who didn't activate churn here
+Month 6:  Second cliff — customers who never expanded, running out of runway
+Month 12: Renewal cliff — annual contract renewal decision
+Month 18: Mature customers — churn rate stabilizes significantly
+
+Healthy curve: Drops sharply in months 1-3, flattens after month 6
+Problem curve: Continues declining linearly through month 12+ (no value anchor)
+```
+
+### Reading Cohort Data
+
+| Pattern | Interpretation | Action |
+|---------|---------------|--------|
+| Early churn (months 1-3) | Onboarding / activation failure | Fix time-to-value, improve onboarding |
+| Mid-cycle churn (months 4-8) | Value not deepening | Adoption program, check product fit |
+| Annual renewal churn (month 12) | Buying committee didn't renew | Executive engagement, earlier renewal process |
+| Flat after month 6 | Sticky product, low expansion | Increase upsell motion |
+| Growing after month 6 | Expansion working | Scale the upsell playbook |
+
+### Cohort Segmentation Variables
+
+Slice retention cohorts by:
+- **Acquisition channel** (inbound vs. outbound vs. PLG vs. partner)
+- **Sales rep** (which reps close durable deals vs. churny deals)
+- **Deal size** (SMB churn rate typically 2-3x enterprise)
+- **Industry vertical** (some verticals have structurally higher churn)
+- **Product tier at signup** (self-serve → converted vs. directly contracted)
+- **Geographic market** (international markets often have different retention profiles)
+
+The most actionable finding is usually by acquisition channel or sales rep — both are directly controllable.
+
+### Churn Prevention Intervention Playbooks
+
+**Playbook 1: Low Activation (no login in first 14 days)**
+```
+Day 7:   Automated email: "Getting started" + specific next step
+Day 14:  CSM outreach: "I noticed you haven't logged in — can I help?"
+Day 21:  Escalate to CSM manager if no response
+Day 30:  Executive outreach for ACV > $25K; flag as at-risk
+```
+
+**Playbook 2: Usage Cliff (DAU drops > 50% in 30 days)**
+```
+Trigger:  Automated health score alert
+Day 1:    CSM reviews usage report, identifies likely cause
+Day 2:    CSM outreach: "We noticed your team's usage changed — is everything okay?"
+Day 7:    If no response: schedule 30-min call with champion
+Day 14:   If unresponsive: VP CS loop-in + executive reach out
+```
+
+**Playbook 3: Champion Departure**
+```
+Trigger:  LinkedIn alert or internal report of champion leaving
+Day 1:    Email to departed champion (warm handoff ask)
+Day 1:    Email to new stakeholder (introduction from AE or VP CS)
+Day 3:    Schedule onboarding call for new stakeholder
+Day 14:   QBR with new stakeholder to establish relationship
+Day 30:   Health score review — flag if engagement hasn't recovered
+```
+
+**Playbook 4: Pre-Renewal (90 days out, health score < 70)**
+```
+Day -90: CSM completes account health review, escalates if < 70
+Day -75: Executive sponsor from vendor side joins renewal call
+Day -60: Value delivered report prepared (ROI proof)
+Day -45: Renewal proposal sent with expansion option
+Day -30: Follow-up on any open objections or requirements
+Day -14: Final confirm or escalate to VP Sales
+```