Capacity Planning: Standards
Objective. Review the handling/productivity standards that convert volume into effort, and insist they come from the customer's measured work, not defaults.
This screen answers: how long does a unit of work take? The standard is the exchange rate from volume to effort, and it scales the entire requirement.
See it in the demo
What this screen answers
The customer question is: what handling time or productivity standard are we using to convert work volume into required effort, per work type. A CSM validates it as a core input; a rep uses it to show the requirement is built from a defensible conversion, not a guess.
The task
Review the standards applied per work type for the scope. The job is to check they are the customer's own measured figures, not seeded or benchmark defaults, and that each work type has a sensible standard.
How to read it
The standard is the conversion from volume to effort - the exchange rate at the heart of the requirement. Because it multiplies through the whole calculation, a wrong standard scales the entire requirement up or down. The classic misread is accepting a default or benchmark standard as if it were the customer's reality. Standards should be derived from the customer's measured work; until they are, the requirement is only as good as a borrowed number.
Honest limits
Standards must be validated against the customer's own baseline - demo values are seeded. A standard is an assumption about effort, not a measurement of this customer's work until they confirm it. Confirm with product how standards are derived or imported for a real deployment.
Interpretation check
A handling standard is the volume-to-effort exchange rate; a wrong standard scales the whole requirement, so it must be the customer's measured figure, not a default.
Practical task
Review the standards for one work type, state how a 10 percent error in the standard would move the requirement, and note that it must be validated against the customer's baseline.
Self-check
Why is the handling standard such a high-leverage input?
It converts every unit of volume into effort, so it multiplies through the whole requirement. A wrong standard scales the entire headcount up or down.
A customer is comfortable with the benchmark standards shown. What do you push on?
Benchmarks are not their reality. Standards should come from the customer's measured work; a borrowed standard makes the requirement only as trustworthy as that borrowed number.
Is a standard a measurement?
Not in the demo - it is a seeded assumption. It becomes trustworthy only once validated against the customer's own baseline.
Verified vs demo. Screen is live in the demo at /#/standards; exact controls and figures are SME-validation-pending.