---
name: capacity-review
description: Produces a capacity planning memo with current utilisation, growth projection, recommended action, and a budget ask for the decision-maker.
version: 1.0.0
author: VantagePoint Networks
audience: IT Managers, Infrastructure Leads, Finance Business Partners, Heads of IT
output_format: Formatted Markdown capacity memo with utilisation dashboard, projection table, scenarios, recommendation, risk summary, and budget ask.
license: MIT
---

# Capacity Review

Turns scattered utilisation metrics into a capacity memo that makes a recommendation, names the trade-off, and asks for the budget you actually need.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. Run `/capacity-review` in Claude Code. Describe what you're reviewing (WAN bandwidth / storage / compute / licences / seats / DC power) and paste the numbers. Answer the growth-driver questions. Receive the memo.

## When to use this

- Annual / quarterly capacity review is due and you need more than "things are mostly fine."
- Budget planning cycle is open and you need a defensible capacity line-item.
- You've hit a threshold on a resource (storage 80%, bandwidth peaking, licence count) and need to decide "add more or optimise."
- A hiring plan or product launch is coming and IT needs to land the infrastructure ask before it's urgent.
- You want every capacity memo in the organisation to follow the same shape so decisions compare.

## What you'll get

- **Scope** - exactly what resources are being reviewed.
- **Current utilisation snapshot** - measured, not estimated, with source.
- **Historical trend** - last 3/6/12 months of utilisation.
- **Growth drivers** - headcount, product launches, policy changes, retention periods.
- **Projection** - next 12/24 months, with confidence range and assumptions.
- **Threshold analysis** - when utilisation hits 80/90/95%, what happens.
- **Scenarios** - do-nothing / optimise-first / scale-up / scale-out / replace - each with cost and risk.
- **Recommendation** - one option, named trade-offs, why this over the others.
- **Risk if not funded** - explicit, dated, quantified.
- **Budget ask** - specific figure, breakdown, funding window.
- **Exec-friendly one-pager** - at the top for the decision-maker.

## Clarifying questions I will ask you

1. **What resource are you reviewing?** (WAN bandwidth / storage / compute / seats / licences / DC power / cooling / rack U / VPN concurrent sessions)
2. **Current utilisation?** (% or absolute - with timestamp and source)
3. **What threshold is considered "concerning" in your environment?** (80% is common for many resources; different for bursty ones)
4. **Historical trend?** (Last N months of same metric)
5. **What's coming that drives growth?** (Headcount, customer growth, retention policy, new product, regulatory data retention)
6. **Seasonal patterns?** (End of month, trading hours, back-to-school, Black Friday)
7. **Technical options known to you?** (Upgrade existing / migrate / add capacity / optimise / retire demand)
8. **Commercial reality?** (Contracts locked in, upgrade paths priced, vendor negotiation possible)
9. **Timeline?** (Must decide by / must deliver by)
10. **Budget envelope?** (Opex line / capex / unfunded and asking)
11. **Decision-maker?** (Line manager, IT Director, CFO, board)
12. **Previous capacity decisions for this resource?** (What have we done before - helpful context)

## Output template

```markdown
# Capacity Review: <resource> - YYYY-MM-DD

**Memo ID:** CAP-<slug>-<YYYY-QN>
**Prepared by:** <name>
**Prepared for:** <decision-maker, role>
**Date:** YYYY-MM-DD
**Decision needed by:** YYYY-MM-DD

## One-page summary (for the decision-maker)
> **What we're reviewing:** <resource - one line>
> **Current state:** <utilisation, condition>
> **Forecast:** <headline trajectory - e.g. "will exceed 90% threshold by Q4 2026">
> **Recommendation:** <option name>
> **Cost:** <figure> (<opex / capex>)
> **Risk of not acting:** <1-2 lines>
> **Alternative considered:** <name>, <why not>

## 1. Scope
- **Resource under review:** <what>
- **Timeframe of analysis:** Past <N> months, projected <N> months forward
- **Population affected:** <users / sites / services>
- **Measurement source:** <monitoring tool / vendor report / manual>

## 2. Current Utilisation
| Metric | Value | As of | Source |
|---|---|---|---|
| Utilisation | <% or absolute> | YYYY-MM-DD HH:MM | <source> |
| Peak last 30 days | <%> | YYYY-MM-DD HH:MM | <source> |
| Avg last 30 days | <%> | <period> | <source> |
| 95th percentile last 30 days | <%> | <period> | <source> |
| Threshold: concerning | <%> |  |  |
| Threshold: critical | <%> |  |  |

## 3. Historical Trend
| Period | Peak | Avg | 95p | Notes |
|---|---|---|---|---|
| YYYY-MM (12 months ago) | <>% | <>% | <>% | <event if any> |
| YYYY-MM (6 months ago) | <>% | <>% | <>% | <event if any> |
| YYYY-MM (3 months ago) | <>% | <>% | <>% | <event if any> |
| YYYY-MM (last month) | <>% | <>% | <>% | <event if any> |

**Observed trend:** <e.g. "Linear growth ~3% per month, consistent with headcount trajectory">
**Anomalies:** <e.g. "Spike in October correlates with product launch; sustained, not transient">

## 4. Growth Drivers
### Confirmed
- <Driver - e.g. "Hiring plan Q4 2026: +40 staff, +40% per-user bandwidth">
- <Driver - e.g. "Data retention extension from 3 to 7 years, +X TB/month">

### Probable (planned but not committed)
- <Driver - e.g. "New customer onboarding Feb 2027: +2000 users">

### Possible (contingent)
- <Driver - e.g. "Regulatory change may require regional data duplication">

## 5. Projection
| Horizon | Low estimate | Central estimate | High estimate | Threshold breach? |
|---|---|---|---|---|
| 3 months | <%> | <%> | <%> | No / Yes (central) / Yes (high only) |
| 6 months | <%> | <%> | <%> | |
| 12 months | <%> | <%> | <%> | |
| 24 months | <%> | <%> | <%> | |

**Key assumptions behind projection:**
1. <Assumption>
2. <Assumption>
3. <Assumption>

**Sensitivity:** If <driver> happens earlier / larger, central estimate moves to high estimate.

## 6. Threshold Analysis
### If utilisation reaches 80%
- Symptom: <e.g. occasional user-visible slowness, no hard failures>
- Lead time needed to remediate: <weeks>

### If utilisation reaches 90%
- Symptom: <e.g. consistent peak-time degradation, queue build-up>
- Lead time needed to remediate: <weeks>

### If utilisation reaches 100%
- Symptom: <e.g. service denial, hard failure, SLA breach>
- Recovery time: <hours/days from order to operational>

## 7. Scenarios

### Scenario A - Do nothing
- **Action:** None
- **Cost:** 0
- **Capacity head-room:** Runs out by YYYY-MM
- **Business risk:** <e.g. "User complaints during peak; SLA breach risk Q3 2026">
- **Verdict:** Not recommended unless <condition>

### Scenario B - Optimise first
- **Action:** <e.g. "Remove dormant accounts, archive cold data, compress">
- **Cost:** <figure, mostly staff time>
- **Capacity head-room:** Buys <N> months
- **Business risk:** <e.g. "Delays the decision but doesn't remove it; frees up <X%> that growth consumes in <Y months>">
- **Verdict:** Recommended as complement, not substitute

### Scenario C - Scale up (vertical)
- **Action:** <e.g. "Upgrade existing appliance to next size">
- **Cost:** <figure> (capex <X>, opex delta <Y> per annum)
- **Capacity head-room:** <N years>
- **Business risk:** <e.g. "Commits to current vendor; single point of failure remains">
- **Verdict:** <>

### Scenario D - Scale out (horizontal)
- **Action:** <e.g. "Add second unit, active-active">
- **Cost:** <figure> (capex <X>, opex delta <Y> per annum)
- **Capacity head-room:** <N years> + improved resilience
- **Business risk:** <e.g. "Higher ongoing complexity; implementation window required">
- **Verdict:** <>

### Scenario E - Replace / re-platform
- **Action:** <e.g. "Migrate from on-prem to cloud / newer platform">
- **Cost:** <figure> + migration effort
- **Capacity head-room:** Structurally different
- **Business risk:** <e.g. "Large-scale change; potential savings long-term; short-term disruption">
- **Verdict:** <>

## 8. Recommendation
**Recommended scenario:** <letter - e.g. Scenario C>

**Why this over the alternatives:**
- <Reason 1 - evidence-based>
- <Reason 2 - evidence-based>
- <Reason 3 - evidence-based>

**Trade-offs accepted by this recommendation:**
- <Honest list - shows the decision-maker we've thought clearly>

**What would change this recommendation:**
- If <trigger> happens, reassess and consider Scenario <X>

## 9. Budget Ask
| Line item | Amount | Funding type | Timing |
|---|---|---|---|
| Hardware / licences | <amount> | Capex | Q<N> 2026 |
| Professional services | <amount> | Opex | Q<N> 2026 |
| Ongoing support / subscription | <amount> | Opex | Annual recurring |
| Contingency (15%) | <amount> | - | - |
| **Total** | **<amount>** | | |

### Cost justification
- <Anchor 1 - e.g. "Current cost per user is X; recommendation preserves that">
- <Anchor 2 - e.g. "3-year TCO compared to do-nothing + emergency remediation estimate">
- <Anchor 3 - if applicable, savings or avoided cost>

## 10. Risk Register Update
| Risk | Current residual | If recommended action taken | If do-nothing |
|---|---|---|---|
| <Capacity breach> | <score> | <lower score> | <higher score> |

## 11. Decision Log (fill after meeting)
- **Decision:** Approved / Approved with changes / Deferred / Rejected
- **Approver:** <name>
- **Date:** YYYY-MM-DD
- **Conditions / changes:** <>
- **Next review:** YYYY-MM-DD
```

## Example invocation

**User:** "/capacity-review - WAN bandwidth at our London HQ. Currently 500Mbps symmetric, we're averaging 310Mbps peak, 95p is 380Mbps. We're hiring 30 more staff over the next 6 months. Video use is growing about 10% a quarter."

**What the skill will do:**
1. Ask whether the WAN is a single circuit or dual-carrier, what the upgrade path looks like (contract terms, next-tier cost), and whether remote working split-tunnel policy is in play (affects HQ bandwidth growth rate).
2. Project: 310Mbps peak + 30 users x avg-per-user + 10%/qtr video growth -> 450Mbps projected peak within 9 months -> 90% threshold breach in <12 months.
3. Scenarios: do nothing (breach late 2026), optimise (split-tunnel policy, video QoS) buys 3 months, scale up to 1Gbps adds 12-18 months runway, scale out with SD-WAN adds resilience.
4. Recommend scale-up with a note that SD-WAN is the right 24-month answer - this buys time for the right design rather than a rushed one.

## Notes for the requester

- **Don't forecast from averages.** Forecast from 95th percentile. Users experience peaks, not averages.
- **Growth drivers trump trend extrapolation.** A clean linear trend can be broken by a product launch that's already signed. Include named drivers.
- **Always present "do nothing" honestly.** The decision-maker must see the cost of inaction to value the cost of action.
- **Name what you'd reconsider.** A recommendation that never changes isn't a recommendation, it's a preference. Triggers for reassessment build trust.
- **Cost anchors matter more than absolute numbers.** "£60k" lands differently as "£20/user/year" vs "20% of annual network opex."
- **"Good" looks like:** the decision-maker approves or defers in one meeting, not three. The finance partner signs off without asking for a rebuild. Six months later, the forecast tracks within the low-central range.