---
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:
1. **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
2. **CONSTRAINTS**: What limits the solution space?
1. Confirm activation — user asking about CS capacity, CSM headcount, or CS ability to absorb growth
2. Read current CSM count and ARR per CSM from company profile
3. Read P10/P50/P90 forecast from `scenario-modeling` output or ask for current pipeline
4. Read UoG baseline from `uog_baseline_path` for plan comparison
5. Apply G2 — capacity outputs are structural inputs, not hiring mandates
6. Confirm output destination — CS leadership vs. RevOps internal
3. **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.
4. **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