name: capacity-calculator
description: Assesses whether a CSM's book of accounts is manageable given the mix of account tiers, health states, upcoming events, and strategic demands. Produces a capacity assessment with overload indicators, rebalancing suggestions, and evidence for headcount conversations. Use when asked to assess workload, evaluate book capacity, determine if a CSM is overloaded, justify additional headcount, plan account distribution, or when a CSM or manager needs to understand whether the portfolio is sustainable. Also triggers for questions about CSM capacity, workload management, account-to-CSM ratios, book balance, portfolio sizing, or when to hire.
license: MIT
metadata:
author: Stephen Rogan
version: "1.0.0"
standalone: true

Capacity Calculator

Assesses whether a CSM's portfolio is manageable by computing the weighted workload across all accounts. Raw account count is a poor measure of capacity -- a CSM with 30 enterprise at-risk accounts is more loaded than a CSM with 80 healthy SMB accounts. This skill computes the actual demand.

How to Use

Provide:
- Your account list with: name, ARR, segment/tier, health status, renewal proximity, and any special circumstances (active escalation, expansion in progress, onboarding)
- Your available hours per week (typically 35-40 after internal meetings and admin)
- Any upcoming capacity constraints (PTO, projects, training)

Capacity Model

Step 1: Compute Per-Account Demand

Each account consumes a different amount of CSM time based on its characteristics:

Base demand by segment:

Demand multipliers:

Per-account demand = Base hours * Product of applicable multipliers

Step 2: Compute Total Portfolio Demand

Sum the per-account demand across all accounts. Compare to available capacity:

Step 3: Classify Capacity Status

Step 4: Identify Rebalancing Opportunities

If overloaded, the skill identifies:

Output Format

## Capacity Assessment: [CSM Name]
**Date:** [date]

### Portfolio Summary
| Segment | Accounts | Base Demand (hrs/mo) |
|---------|----------|---------------------|
| Enterprise | [n] | [hours] |
| Mid-Market | [n] | [hours] |
| SMB | [n] | [hours] |

### Demand Modifiers
| Factor | Accounts Affected | Additional Demand (hrs/mo) |
|--------|------------------|--------------------------|
| At Risk | [n] accounts | +[hours] |
| Critical | [n] accounts | +[hours] |
| Renewal <90 days | [n] accounts | +[hours] |
| Onboarding | [n] accounts | +[hours] |
| Active escalation | [n] accounts | +[hours] |

### Capacity Status
- Total demand: [hours/month]
- Available capacity: [hours/month]
- Utilisation: [%]
- Status: [Underloaded / Healthy / Stretched / Overloaded / Critical]
- Buffer: [hours/month available for unplanned work]

### Top Demand Accounts
[5 accounts consuming the most CSM time, with demand breakdown]

### Recommendations
[Rebalancing suggestions if overloaded, or strategic opportunities if underloaded]

Using This for Headcount Justification

The capacity model produces the evidence a CS leader needs to make a hiring case:

Frame the ask as: "At current utilisation, we are deferring [X hours/month] of proactive work that protects [EUR Y] in ARR. A new hire at [cost] would recover [Z] hours of capacity and reduce the unprotected ARR."

Quality Gates

• Are the segment classifications accurate? An account labelled "SMB" that actually requires mid-market engagement will undercount demand
• Are the multipliers applied honestly? Tempting to downplay the demand of at-risk accounts to make the number look manageable. The model is only useful if it reflects reality
• Does the buffer account for realistic variability? A month with zero surprises is fiction. 15-20% buffer is the minimum for a sustainable portfolio
• If overloaded, is the rebalancing recommendation specific? "Reduce workload" is not a recommendation. "Transfer 5 SMB accounts (EUR 35k combined ARR, all healthy) to scaled motion to free 8 hours/month" is

Principles

• Account count is a vanity metric. Capacity is a function of ARR-weighted, health-adjusted, event-modified demand -- not the number of logos on the list. 40 accounts is not a meaningful statement without knowing the mix
• Chronic overload is a management failure, not a CSM resilience test. A CSM operating at 110% utilisation for 3 months is not performing heroically -- they are being set up to fail. The capacity model makes this visible
• The capacity model is an argument, not a complaint. Presenting utilisation data with revenue impact and risk quantification is a business case. Saying "I am too busy" is a complaint. The model produces the former
• Underloaded CSMs are an opportunity, not a problem. If utilisation is below 70%, the CSM has room for deeper strategic work, more accounts, or both. Use the capacity data to make that case as well