capacity-planner

---
name: capacity-planner
description: Use when sizing an ops team (Support, CX, BizOps, IT, Finance ops) handling queued work — headcount planning, utilization risk, or a quarterly hiring sequence.
category: Business Operations
version: 1.0.0
tools: []
---

# Capacity Planner

Sizing tool for ops teams that handle queued work — Support, CX, Customer Success, BizOps, IT ops, Finance ops — built on Erlang-C queueing theory, Little's Law, and the operational-leadership canon (Fournier, Larson, Cleveland, Reinertsen).

## Purpose

For an ops leader scaling a team with no idea how it will behave at peak load, already at 88% utilization with SLA slipping, or holding an approved hiring budget that needs sequencing across four quarters without burning out the existing team — this replaces vibes with arithmetic. It produces three outputs: (1) capacity sizing at 70/80/90% utilization against P50/P90/P99 demand, with P(SLA breach) at each point and a SAFE/WATCH/AT_RISK/CRITICAL risk band; (2) utilization health at the per-member traffic-light level plus a team verdict of HEALTHY/SQUEEZED/OVERLOADED/UNBALANCED; (3) a 12-month quarterly hiring plan accounting for ramp curves, attrition, quarter-over-quarter demand growth, and span-of-control manager triggers.

## When to use

Annual ops capacity planning (typically October-November for the following fiscal year); quarterly re-sizing when demand shifts more than 15% or attrition spikes; pre-budget defense — the math behind a headcount ask to the CFO; diagnosing whether a team missing SLA has a sizing problem, a process problem, or a bottleneck problem; and sizing a new or combined team for M&A or a new-segment launch.

## Methodology

1. **Intake demand.** Pull P50/P90/P99 daily ticket/case volume from the work system. If only averages exist, get the distribution first — single-point demand estimates are the most expensive anti-pattern in ops.
2. **Model throughput.** Apply Erlang-C sizing with demand, average handle time, SLA target, current headcount, and shrinkage, adjusted for the function (support / CX / bizops / finance-ops / IT-ops). The 80%-utilization row is generally the right sizing point.
3. **Flag utilization risk.** Assess the current team's actual utilization: anyone sustained above 85% is a throughput-collapse risk per Reinertsen Principle 12. A spread over 30 percentage points across the team is UNBALANCED — fix that before hiring.
4. **Sequence hiring.** Build a 12-month quarterly plan from current FTE, target end-of-year headcount, ramp time, attrition, and growth. Front-load hires (roughly Q1 35%, Q4 15%), apply ramp curves, and trigger a manager hire once span of control crosses 7 ICs per manager.
5. **Walk the forcing-question library below, one question at a time, writing down each answer before committing the plan.**

## Canon

Queueing theory: Erlang, Little, Hopp & Spearman, Reinertsen, Kingman, Cleveland, ITIL, Armony et al. Ops workforce planning: Fournier, Larson, the Google SRE Workbook, Frei, Lawler, Bersin, Gartner, Grove. Capacity anti-patterns: eleven named patterns citing Lencioni, Goldratt, and Christensen among others.

## Assumptions

Work is queued (tickets, cases, work items), not project-style — if not, this is the wrong tool. Demand has a stationary-enough distribution within a quarter; step-changes (new product launch, M&A, regulatory shift) require re-running mid-quarter. At least 90 days of historical demand data exists to compute P50/P90/P99 — otherwise, derive the distribution from a sales/user-base forecast first. Service is single-class within a queue; hard priority tiers (P1/P2/P3 with tier-specific SLAs) should be modeled as separate queues and summed. Channels are modeled coherently, using the function's shrinkage premium for multi-channel teams.

## Anti-patterns

Planning to 100% utilization (Reinertsen Principle 12); treating ramp as instant (Larson); ignoring attrition in a 12-month plan (Bersin); hiring ICs forever with no manager trigger (Fournier); sizing to P50 demand only (Cleveland); skipping the shrinkage adjustment (Cleveland, SRE Workbook); using a single-channel model for multi-channel work (Gartner, Kingman); having no surge plan for P99 events (Hopp & Spearman, Reinertsen).

## Distinct from

Engineering-throughput tools measure DORA metrics, story points, and deployment cycle time for teams shipping code — different unit of work and math. Strategic workforce planning covers 1-5 year capability portfolios and succession, not 0-12 month operational sizing — conflating the two gets people hired into the wrong jobs (Lawler). Project-management tools track delivery throughput (Jira velocity, sprint capacity) rather than steady-state queued work. A process-mapper skill finds the bottleneck; this skill sizes the team around a known bottleneck — run process mapping first, since hiring around the wrong constraint wastes the hires. A CS-coverage approach sizes relationship coverage by ARR/CSM ratio; this skill sizes by queued-work volume — run both for a team that does both.

## Forcing-question library

Walk these one at a time. Do not skip ahead. Write down every answer — if one can't be answered, that's the next investigation.

1. **What is your bottleneck, and have you confirmed it empirically?** Recommended: a named, measured stage with queue-time data, not a vibe. Per Goldratt (*The Goal*, 1984), every system has exactly one binding constraint at a time — sizing around the wrong one wastes hires entirely. If the bottleneck isn't known, map the process before sizing it.
2. **What service trade-off are you accepting?** Recommended: a written, explicit choice — fast vs. empathetic, broad vs. deep, low-cost vs. high-quality. Per Frances Frei (*Uncommon Service*, 2012), no team wins all four; the team that tries wins zero. AHT, SLA, and shrinkage inputs are the operational expression of this trade-off, and they must agree with each other.
3. **What's your demand P90, and what's the gap to your P99?** Recommended: two specific numbers from the last 90 days with calendar context. A team sized to P50 misses SLA half the time; a team sized to P99 overstaffs by 30-50%. P90 is the right sizing point per Cleveland (*Call Center Management on Fast Forward*), building on A.K. Erlang's original 1909 work, *The Theory of Probabilities and Telephone Conversations*.
4. **At your planned utilization, what is P(SLA breach) at P90 and at P99?** Recommended: two probabilities computed from Erlang-C with the specific headcount, AHT, and SLA target — not guessed. Above 10% breach probability at P90 means understaffed at the sizing point; above 50% at P99 means no surge plan, and the next peak event becomes visible to the CEO (Hopp & Spearman, *Factory Physics*, VUT equation).
5. **Have you budgeted replacement hires for this year's attrition?** Recommended: yes, with a specific number. At roughly 30% annual attrition (Bersin/Deloitte midpoint), a 20-FTE team loses about 6 people a year — an "add 5 net" plan is often actually an "hire 11" plan.
6. **When does span of control trigger a manager hire, and who is the candidate?** Recommended: a specific quarter and at least one identified candidate. Past 7 ICs per manager, 1:1s degrade and feedback cycles slip (Fournier, *The Manager's Path*; Grove, *High Output Management*); past 10, it's a coverage crisis — hire before crossing 10, not after.
7. **What is your surge plan for the P99 day?** Recommended: an explicit, documented plan — overflow tier, contracted BPO capacity, on-call rotation, executive escalation tree, or a written degradation contract (e.g. "on P99 days we extend SLA to X minutes and notify customers proactively"). "We'll figure it out" means the P99 day becomes a fire visible to the board (Reinertsen, capacity-margin discipline).

Walk these seven in order, one at a time, answers written down — the plan is only as defensible as the answers to these seven questions.