Capacity Planning: Planning policies
Objective. Validate the planning-policy defaults (such as shrinkage, occupancy caps, rounding) that silently drive every requirement - confirm they are the customer's real figures, escalate deep setup.
Planning policies are the default assumptions - shrinkage, occupancy caps, rounding and similar rules - that silently shape every requirement in the plan. A CSM validates these are the customer's real figures, not placeholders.
See it in the demo
What this screen answers
A CSM opens this to answer 'what assumptions is the plan quietly applying to every number?' Policies like shrinkage and occupancy are applied everywhere, so a placeholder here distorts the whole plan without appearing on any single requirement. This screen is where those defaults are checked.
The task (validate, do not re-engineer)
Scope to the customer and confirm the key policy assumptions - above all shrinkage and occupancy - are the customer's real figures. Flag anything that looks like a default placeholder. This is validation and escalation: confirm the assumptions are correct; leave policy structure design to the specialist. Describe it as 'the planning-policy defaults in force for this scope'.
How to read it
A policy default here is a silent multiplier on the whole plan, not a harmless setting. The misread is scrutinising the headline requirement while ignoring the policy that produced it. Shrinkage especially swings the requirement heavily - a placeholder shrinkage can make a plan look adequate or short for no real reason. Read these defaults first; they explain requirements that otherwise look surprising.
Honest limits
This screen does not prove the policies are right - only what they are set to. It is admin configuration; confirm the figures with the customer and product, and escalate structural policy changes to the specialist rather than editing them in a customer session.
Interpretation check
Planning-policy defaults such as shrinkage and occupancy silently drive every requirement - validate they are the customer's real figures, not placeholders, and escalate structural setup.
In the field
Any staffing plan: a demo-default shrinkage left in place quietly understates the requirement by double digits - validating it is the highest-leverage correctness check a CSM can make before trusting a plan.
Practical task
Review the planning policies for one scope and write one line confirming (or questioning) the shrinkage and occupancy figures as the customer's real values, flagging any that look like defaults.
Self-check
Why check planning policies before the headcount number?
Policies like shrinkage and occupancy are applied to every requirement. A placeholder here distorts the whole plan invisibly, so the defaults explain surprising requirements and must be validated first.
Which policy most swings the requirement?
Shrinkage (with occupancy close behind). A wrong shrinkage figure can make a plan look adequate or short with no real change in work - it must be the customer's actual figure.
What is the CSM's boundary on this screen?
Validate that the defaults are the customer's real figures and flag placeholders - not redesign the policy structure, which is a specialist setup task.
Verified vs demo. Screen is live in the demo at /#/policies; exact controls and figures are SME-validation-pending.