| name | closed-won-to-cs-capacity-modeling |
| version | 1.0.0 |
| deployment_target | plugin |
| status | PROPOSED |
| description | Converts rolling sales forecast into CS resource demand using UoG formulas. Runs three-scenario capacity check (P10/P50/P90 from scenario-modeling). Compares projected CSM demand to current headcount and UoG annual plan baseline. Surfaces CS capacity gaps with a hiring lead time flag. Updates when SA1 forecast moves >10%. Triggers: 'CS capacity', 'can CS absorb', 'CSM headcount needed', 'CS ceiling', 'will CS be able to handle new logos'. |
[PROPOSED]
Closed-Won to CS Capacity Modeling
Translates what Sales is about to close into what CS needs to handle.
The skill that prevents hiring CSMs one quarter after you needed them.
Reference: UoG formulas (CS capacity) → ../../../shared/revops-domain-model.md §5
Config reads: current_csm_count, arr_per_csm, avg_deal_acv,
csm_avg_ramp_days, uog_baseline_path, open_csm_requisitions
Use when
- CS team capacity needs to be assessed against incoming closed-won volume
- Onboarding capacity planning requires modeling against pipeline close projections
- CS hiring or resource decisions need to be tied to revenue intake rate
Upstream dependency: Before using this skill, establish current CSM load and coverage ratios using the CS Ops plugin's capacity-planner skill (if the cs-ops plugin is installed, run /cs-ops:capacity-planner) — this skill models incoming volume against that capacity baseline.
Do NOT use for
- Individual CS assignment decisions (use handoff workflow)
- CS performance assessment
- Pipeline coverage analysis from a Sales perspective (use pipeline-coverage-analysis)
Typical Activation
"CS capacity model", "can CS absorb this pipeline", "capacity planning for CS", "closed-won to onboarding capacity", "do we have enough CS capacity"
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: current_csm_count, arr_per_csm, avg_deal_acv, csm_avg_ramp_days, uog_baseline_path, open_csm_requisitions
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.
Reasoning Protocol
Before generating output, apply these primers:
-
CLASSIFY: What type of CS capacity request is this?
- Current-state headroom check (no forecast context)
- Three-scenario demand modeling (P10/P50/P90)
- Plan comparison (vs. UoG annual baseline)
- Hiring lead time assessment
-
CONSTRAINTS: What limits the solution space?
- Confirm activation — user asking about CS capacity, CSM headcount, or CS ability to absorb growth
- Read current CSM count and ARR per CSM from company profile
- Read P10/P50/P90 forecast from
scenario-modeling output or ask for current pipeline
- Read UoG baseline from
uog_baseline_path for plan comparison
- Apply G2 — capacity outputs are structural inputs, not hiring mandates
- Confirm output destination — CS leadership vs. RevOps internal
-
EXPERT CHECK: What would a veteran RevOps analyst verify first?
- Is the UoG baseline present? If absent, declare and run in current-state mode only.
- Is the ARR-per-CSM target current? Stale targets produce misleading headroom signals.
- Is hiring lead time factored in? A gap identified today may already be too late for the quarter.
- Is the CS constraint signal checked before any AE growth discussion? CS ceiling can invalidate an AE plan.
-
ANTI-PATTERNS: Common mistakes to avoid:
- Presenting capacity outputs as hiring mandates (G2 violation)
- Running plan comparison without checking whether the baseline path is configured
- Omitting the hiring lead time flag when CS_Gap > 0
- Ignoring the CS headroom signal when advising on AE headcount growth
After execution, verify:
- G2 structural input qualifier present on all capacity outputs
- Data-as-of label applied per G6
- Hiring lead time flag included when CS_Gap > 0
- Confidence: High when baseline is present and all config fields are populated; Moderate when baseline is absent or any field is estimated
- Confidence: [High] when baseline is present and all config fields populated / [Medium] when baseline is absent or any field is estimated / [Low] if all inputs are manual or unverified
Three-Scenario Capacity Check [revops-domain-model.md §5]
For each scenario (P10 / P50 / P90):
New_Customers = Scenario_New_ARR ÷ avg_deal_acv (if available)
Total_Future_ARR = current_arr + Scenario_New_ARR
CSMs_Required = CEILING(Total_Future_ARR ÷ arr_per_csm)
CS_Gap = CSMs_Required − current_csm_count
Constraint_Signal = derived from CS Headroom % thresholds [domain-model §5]
CS headroom signal thresholds [revops-domain-model.md §5]:
- < 0% → CS already over capacity — churn risk live NOW
- 0–10% → Near ceiling — CS hiring is primary constraint
- 10–25% → Limited headroom — model next quarter before hiring AEs
-
25% → Healthy headroom
Plan comparison:
If UoG baseline present: compare CSMs_Required to baseline csm_required.
Surfaces: are we ahead of, on, or behind the plan's CS hiring assumptions?
Hiring lead time flag:
If CS_Gap > 0:
Hire_By = quarter_close_date − csm_avg_ramp_days
If Hire_By < today:
→ "CS ramp period means any hire today won't be productive before Q[N] close."
Output
CS CAPACITY MODELING — [Quarter/Period]
[Company profile] [Confidence: High/Moderate]
[UoG baseline: present / absent]
Current state:
CSMs in seat: [N] Open reqs: [N]
ARR per CSM target: $XXXk
CS headroom today: XX% ([Signal])
Three-scenario demand:
Scenario New ARR CSMs needed CS gap Headroom Signal
P10 $XXXk N [+N/-N] XX% [HEALTHY/AT-RISK/CRITICAL]
P50 $XXXk N [+N/-N] XX% [signal]
P90 $XXXk N [+N/-N] XX% [signal]
vs. annual plan baseline: [N CSMs planned → N required at P50 — on/ahead/behind plan]
Hiring lead time:
At P50: hire [N] CSMs by [date] to be productive by [quarter close]
Current ramp: [csm_avg_ramp_days] days
[DRAFT — RevOps and CS leadership]
[G2: Structural input. Hiring requires budget approval and HR process.]
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
- G2: Always include the structural input qualifier
- G6: Data-as-of on all connector reads
- When baseline absent: declare before analysis; run in current-state mode only
