t0ddc3by/claude-for-customer-success/closed-won-to-cs-capacity-modeling

[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

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

1. 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.

1. 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

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