Capacity Planning: Organisation
Objective. Validate that the organisation structure the plan rolls up through matches the customer's planning scope - confirm scope, escalate structural setup.
The organisation screen holds the hierarchy (teams, sites, departments) the plan rolls up and down through. A CSM validates it reflects the planning scope, so requirements aggregate to the right units.
See it in the demo
What this screen answers
A CSM opens this to answer 'does the plan's structure match how the customer actually organises and plans?' Requirements roll up and down this hierarchy, so if it is wrong, aggregated numbers land against the wrong units. This screen is where that structure is confirmed.
The task (validate, do not re-engineer)
Scope to the customer and confirm the organisation reflects the teams, sites or departments the plan should cover, at the right granularity. Check that nothing material is missing or misplaced. This is validation and escalation - confirm the structure serves planning; leave structural redesign to the specialist. Describe it as 'the org structure configured for planning'.
How to read it
The org tree here is planning configuration, not a live mirror of HR. The misread is assuming it is automatically current with the customer's real org or HR system. Read it for whether it matches the planning scope the customer expects; a stale or mismatched structure makes rollups and coverage reads misleading even when the underlying numbers are fine.
Honest limits
This screen does not prove the structure is synced with the customer's HR system of record - confirm with product how, or whether, it is kept current. It is admin configuration; escalate structural changes to the specialist rather than editing in a customer session.
Interpretation check
The org structure here is planning configuration, not a guaranteed live mirror of HR - validate it matches the planning scope, and escalate structural setup rather than re-engineering it.
In the field
A multi-site RCM provider: if a site or team is misplaced in the hierarchy, the portfolio rollup hides a local shortfall - validating the structure keeps aggregated capacity reads trustworthy.
Practical task
Review the org structure for the customer's scope and write one line confirming it matches their planning units, naming any missing or misplaced unit to raise with the specialist.
Self-check
Can you assume the org tree matches the customer's current HR org?
No. It is planning configuration; confirm with product whether and how it syncs to the HR system of record. A stale structure makes rollups misleading even with good numbers.
What is the CSM confirming here?
That the hierarchy covers the right teams/sites/departments at the right granularity for planning - scope and correctness, not redesigning the structure.
Why does a wrong org structure matter if the numbers are right?
Requirements roll up and down this hierarchy; a misplaced unit lands aggregated numbers against the wrong group, so coverage and totals read wrong despite correct inputs.
Verified vs demo. Screen is live in the demo at /#/org; exact controls and figures are SME-validation-pending.