Capacity Planning - Concepts and Key Terms
Objective. Give Sales and CSM the mental model behind Capacity Planning and a plain-language glossary of its key terms, so they can reason about the app rather than memorise screens - and get right the one concept people most often confuse.
Capacity Planning rests on one idea: turn a demand projection into a defensible staffing requirement by applying stated, testable assumptions, then set that requirement against available capacity to expose the gap - read by skill and interval, not as a lump. This module defines the core concept, the eight or so terms you need to use the app fluently, how the concepts chain from demand to a sized requirement, and the single distinction (requirement versus execution) that trips people up most.
See it in the demo
The core concept
The whole app is one transformation: demand -> effort -> required capacity -> gap against available capacity, with every step governed by an assumption you can see and test.
Start with projected demand (volume by period and work type). Apply handling standards to turn volume into effort. Discount effort by shrinkage and cap it by occupancy to turn nominal people into effective capacity needed - the required FTE sized to a service goal. Set that requirement against available capacity (the workforce and their skills) to find the gap - by skill and interval, not just a total.
The point of the app is not the final number; it is making the assumptions behind the number explicit and sensitivity-testable so the requirement is defensible. A forecast is a projection with error bars; a plan or scenario is a simulation, not an execution; required FTE depends on its standards, shrinkage and occupancy assumptions; and model accuracy is backtested, not guaranteed. Hold those four and the app makes sense.
Key terms - a plain glossary
- Volume / demand forecast: projected arriving work by period and work type. A projection with error bars - not actuals, not effort, not staffing.
- Work drivers: what generates workload - volume, mix, rework, backlog. The mix, not just the total, decides which skills are needed.
- Handling / productivity standard: the figure that converts a unit of volume into effort (time per unit). The hinge between demand and people; defaults are usually wrong for a customer.
- Shrinkage: the share of paid time not available for the work (leave, training, breaks, off-phone). Turns nominal headcount into effective FTE and swings the requirement heavily.
- Occupancy: how fully available time can be loaded before it is unsustainable; a cap applied in planning policy.
- Required capacity / required FTE: the computed number of effective people and skills needed to meet the service goal under the stated assumptions.
- Available capacity: the workforce actually on hand and what skills they hold.
- Service level / service goal: the target the plan is sized to hit (an input, not an achieved result).
- Skills and credentials: which people can do which work; why a plan is skills-in-intervals, not a headcount lump.
- Scenario / what-if: an alternative assumption set held side by side to show sensitivity; a simulation, not a commitment.
- Forecast accuracy and bias: how well the model predicted historically (accuracy = error size; bias = consistent over/under lean). Backtested, not a guarantee.
- Balancing / coverage: comparing required against available by skill and interval to expose gaps the headline total hides.
How the concepts chain together
Follow one unit of work through the model:
- Demand projects, say, 1,000 cases next week (volume forecast, with error bars).
- Work drivers split that by type and flag rework/backlog, so you know the mix and therefore the skills in play.
- Handling standards convert each case-type into effort - 1,000 cases becomes a number of work-hours.
- Shrinkage discounts available time and occupancy caps loading, converting effort-hours into effective FTE required.
- That required FTE is sized to a service goal - move the goal and the requirement moves.
- Available capacity and skills give the other side of the balance.
- Balancing compares the two by skill and interval to show the gap.
- Scenarios/what-if vary one assumption to show how sensitive the gap is; forecast accuracy/bias says how much to trust the demand that started it all.
Each arrow is an assumption. The value of the app is that you can see and test every arrow, so the final gap is defensible rather than a buried guess.
The one concept people get wrong most
The distinction people collapse most often is requirement versus execution (and its cousin, projection versus result).
Capacity Planning produces a requirement - how many effective people and skills you would need, by interval, to meet a goal under stated assumptions. It does not hire anyone, schedule anyone, or achieve any service result. A scenario is simulated; a capacity review being approved is an owned decision on the requirement, not the act of staffing to it; a service goal in the plan is a target it is sized to, not an outcome it delivers.
So the habit to build: whenever someone treats a capacity figure as done - 'we're staffed', 'we'll hit SLA', 'that's the saving' - name which thing it actually is. It is a projection (demand), a simulation (scenario), or a requirement (FTE) - never an executed action, a guaranteed result, or a cash amount. Execution lives in Scheduling and real hiring; achievement is measured in operation; cash is realised by a separate customer decision. Keeping requirement separate from execution is the concept the entire app's honesty depends on.
Interpretation check
Capacity Planning transforms a demand projection into a required capacity through a chain of explicit assumptions (standards, shrinkage, occupancy, service goal), then compares it to available capacity by skill and interval. The output is a requirement, not an executed plan or a guaranteed result.
Practical task
Draw the demand-to-gap chain for one work type from the demo: label each arrow with the assumption it applies (standard, shrinkage, occupancy, service goal), then write a one-line definition of five of the glossary terms in your own words and mark, for each figure the chain produces, whether it is a projection, a simulation, or a requirement.
Self-check
In one sentence, what transformation is the whole app built on?
It turns a demand projection into a required capacity by applying stated assumptions (standards, shrinkage, occupancy, service goal) and compares that requirement to available capacity by skill and interval to expose the gap.
Define handling standard and shrinkage, and say why each matters.
A handling standard converts a unit of volume into effort (time per unit) - the hinge from demand to people. Shrinkage is the share of paid time not available for the work; it turns nominal headcount into effective FTE and swings the requirement heavily. Both are usually wrong as defaults.
Why is a capacity plan expressed as skills-in-intervals rather than a headcount total?
Because different work types need different skills at different times. A net total can be balanced while a scarce skill is short at peak, so coverage must be read by skill and interval (balancing).
What is the single concept people most often get wrong, and how do you correct it?
Requirement versus execution. The app produces a requirement, not a hire, a schedule, a guaranteed service result or a cash saving. Correct it by naming which thing a figure actually is: a projection, a simulation, or a requirement.
What is the difference between forecast accuracy and bias?
Accuracy is the size of the historical error; bias is a consistent lean over or under. Both are backtested, not guaranteed, and a biased forecast systematically mis-staffs even when average error looks small.
Verified vs demo. The concept model and term definitions describe the app's demo logic on seeded data; exact formulas, the forecasting method and the accuracy metric are confirm-with-product. The definitions are at app-logic level, not a claim about a customer's specific configuration.