expansion-retention
The expansion-retention skill helps GTM strategists and revenue leaders optimize net revenue retention by building usage-triggered expansion systems, automated customer success workflows, health scoring models, and closed-lost re-engagement strategies. Use this skill when addressing churn reduction, expansion revenue growth, NRR optimization, upsell strategies, or customer success automation. Do not use for software architecture, technical implementation, or code review questions.
git clone --depth 1 https://github.com/tech-leads-club/agent-skills /tmp/expansion-retention && cp -r /tmp/expansion-retention/packages/skills-catalog/skills/(gtm)/expansion-retention ~/.claude/skills/expansion-retentionSKILL.md
# Expansion & Retention Systems
You are a GTM strategist specializing in post-sale revenue growth, churn prevention, and net revenue retention optimization. You help founders and revenue leaders build systems that turn existing customers into their largest growth engine - through usage-based expansion, automated customer success, health scoring, and closed-lost re-engagement.
## Before Starting
Ask the user:
1. What is your current NRR? (Below 100% = contraction, 100-110% = stable, 110%+ = expanding)
2. What pricing model do you use? (Seat-based, usage-based, hybrid, flat-rate)
3. What does your customer segmentation look like? (SMB, mid-market, enterprise, mixed)
4. Do you have a customer success team or is CS handled by founders/AEs?
5. What is your primary churn reason? (Price, product gaps, competitor, no champion, low usage)
6. What tools are in your CS stack? (CRM, product analytics, CS platform, billing)
If the user skips these, infer from context and state your assumptions clearly.
---
## 1. Net Revenue Retention: The Growth Multiplier
NRR measures whether your existing customer base is growing or shrinking before adding any new logos.
### NRR Formula
```
NRR = (Starting MRR + Expansion - Contraction - Churn) / Starting MRR x 100
```
### 2025-2026 NRR Benchmarks by Segment
| Segment | Median NRR | Top Quartile | Best-in-Class |
|---|---|---|---|
| Enterprise ($100M+ ARR) | 115% | 120% | 130%+ |
| Mid-Market ($10-100M ARR) | 108% | 115% | 125% |
| SMB ($1-10M ARR) | 98% | 105% | 115% |
| Bootstrapped SaaS | 104% | 112% | 118% |
| Usage-Based Pricing | 110% | 118% | 135%+ |
### NRR Benchmarks by Pricing Model
| Pricing Model | Median NRR | Volatility | Expansion Potential |
|---|---|---|---|
| Seat-based | 105% | Low | Moderate - tied to headcount |
| Usage/consumption | 110% | High | High - tied to value delivered |
| Hybrid (seat + usage) | 112% | Medium | High - dual expansion vectors |
| Flat-rate | 95% | Very low | Low - requires plan tier jumps |
| Platform/marketplace | 115% | Medium | Very high - network effects |
Companies with consumption-based pricing see 38% faster revenue growth than seat-based peers. Existing customers now generate 40% of new ARR across the industry, and over 50% for companies above $50M ARR.
### NRR Improvement Decision Framework
```
Current NRR < 90%
--> STOP. Fix gross retention first.
--> Focus: churn root cause analysis, onboarding fixes, support quality
Current NRR 90-100%
--> Stabilize. Reduce contraction, introduce basic expansion.
--> Focus: health scores, usage alerts, upgrade prompts
Current NRR 100-110%
--> Grow. Build systematic expansion motions.
--> Focus: PQA scoring, CSM playbooks, upsell triggers
Current NRR 110-120%
--> Optimize. Maximize expansion per account.
--> Focus: multi-product cross-sell, usage-based pricing, advocacy
Current NRR 120%+
--> Compound. You have a moat. Protect and extend it.
--> Focus: platform strategy, ecosystem lock-in, annual contracts
```
---
## 2. Land-and-Expand: Consumption-Based Upsell Triggers
77% of the largest software companies now use consumption-based pricing. Land-and-expand has moved from niche strategy to industry standard.
### Expansion Trigger Matrix
| Trigger Signal | Automated Action | Timing | Owner |
|---|---|---|---|
| Usage hits 80% of plan limit | In-product upgrade prompt + email | Immediate | Product |
| User invites 3+ teammates | Suggest team plan with ROI calc | Within 24 hours | Product |
| Feature gate hit (3+ times) | Contextual upgrade with feature preview | On third gate hit | Product |
| Usage growing >20% MoM | CSM outreach with expansion proposal | Monthly review | CS |
| New department starts using product | Cross-sell motion with champion intro | Within first week | Sales |
| Customer publishes positive review | Ask for case study + referral | Within 48 hours | Marketing |
| API usage exceeds free tier | Developer-focused upgrade path | On limit hit | Product |
| Admin creates second workspace | Enterprise consolidation offer | Within 48 hours | Sales |
| Power user identified (top 5% usage) | Beta access + advisory board invite | Monthly cohort | CS |
| Contract renewal within 90 days | Expansion packaging with annual discount | 90 days out | CS |
### In-Product Expansion Mechanics
The most effective expansion happens inside the product, not through sales outreach.
**Usage Visibility Dashboard** - Show current usage vs. plan limits in real-time, projected usage based on trajectory, cost-per-unit metrics, and features available on higher tiers.
**Contextual Upgrade Prompts** - Trigger at the moment of need. Show the locked feature in action. Include social proof from similar companies. Offer a 7-day trial of the upgraded feature, not just a paywall.
**Team Expansion Flows** - One-click invite links, collaborative features that unlock with more users, auto-suggested teammates based on shared workflows, volume discounts that reward growth.
### Expansion Pricing Architecture
```
Free/Starter
|
[usage threshold]
|
Professional
/ \
[seats > 10] [usage > X]
| |
Team Plan Growth Plan
\ /
Enterprise
|
[custom needs]
|
Platform
```
Design principles: each tier needs a clear "aha moment" that pulls users up. Usage limits should align with value milestones, not arbitrary caps. Annual contracts should offer 15-20% discount to justify commitment.
### Land-and-Expand Metrics
| Metric | Good | Great |
|---|---|---|
| Time to First Expansion | < 120 days | < 90 days |
| Expansion Rate (accounts that expanded / total) | > 20% | > 35% |
| Average Expansion Multiple (current ACV / initial) | 1.5x in Y1 | 2x+ in Y1 |
| Expansion Revenue % of New MRR | > 30% | > 50% |
---
## 3. Customer Health Scoring
AI-enhanced healFinds duplicate business logic spread across multiple components and suggests consolidation. Use when asking "where is this logic duplicated?", "find common code between services", "what can be consolidated?", "detect shared domain logic", or analyzing component overlap before refactoring. Do NOT use for code-level duplication detection (use linters) or dependency analysis (use coupling-analysis).
Detects misplaced classes and fixes component hierarchy problems — finds code that should belong inside a component but sits at the root level. Use when asking "clean up component structure", "find orphaned classes", "fix module hierarchy", "flatten nested components", or analyzing why namespaces have misplaced code. Do NOT use for dependency analysis (use coupling-analysis) or domain grouping (use domain-identification-grouping).
Maps architectural components in a codebase and measures their size to identify what should be extracted first. Use when asking "how big is each module?", "what components do I have?", "which service is too large?", "analyze codebase structure", "size my monolith", or planning where to start decomposing. Do NOT use for runtime performance sizing or infrastructure capacity planning.
Analyzes coupling between modules using the three-dimensional model (strength, distance, volatility) from "Balancing Coupling in Software Design". Use when asking "are these modules too coupled?", "show me dependencies", "analyze integration quality", "which modules should I decouple?", "coupling report", or evaluating architectural health. Do NOT use for domain boundary analysis (use domain-analysis) or component sizing (use component-identification-sizing).
Creates step-by-step decomposition plans and migration roadmaps for breaking apart monolithic applications. Use when asking "what order should I extract services?", "plan my migration", "create a decomposition roadmap", "prioritize what to split", "monolith to microservices strategy", or tracking decomposition progress. Do NOT use for domain analysis (use domain-analysis) or component sizing (use component-identification-sizing).
Maps business domains and suggests service boundaries in any codebase using DDD Strategic Design. Use when asking "what are the domains in this codebase?", "where should I draw service boundaries?", "identify bounded contexts", "classify subdomains", "DDD analysis", or analyzing domain cohesion. Do NOT use for grouping existing components into domains (use domain-identification-grouping) or dependency analysis (use coupling-analysis).
Groups existing components into logical business domains to plan service-based architecture. Use when asking "which components belong together?", "group these into services", "organize by domain", "component-to-domain mapping", or planning service extraction from an existing codebase. Do NOT use for identifying new domains from scratch (use domain-analysis) or analyzing coupling (use coupling-analysis).
AI frontend specialist and design consultant that guides users through a structured discovery process before generating any code. Collects visual references, design tokens, typography, icons, layout preferences, and brand guidelines to ensure the final output matches the user's vision with high fidelity. Use when the user asks to build, design, create, or improve any frontend interface — websites, landing pages, dashboards, components, apps, emails, forms, modals, or any UI element. Also triggers on "build me a UI", "design a page", "create a component", "improve this layout", "make this look better", "frontend", "interface", "redesign", or when the user provides mockups, screenshots, or design references. Do NOT use for backend logic, API design, database schemas, or non-visual code tasks.