Time and Activity: Organisation
Objective. Understand that the org structure (teams, membership, reporting lines) defines every team rollup and manager scope - enough to validate that aggregates are trustworthy and escalate deep setup.
This screen answers 'how are people grouped into teams and who rolls up to whom?' It is the structure that every team-level number and every manager's view is built on.
See it in the demo
What this screen answers
A CSM opens this to answer 'when I read a team number, is the team actually made of the right people?' Sales needs awareness that rollups depend on this mapping. The org tree decides which individuals aggregate into a team figure and which manager sees which group, so it quietly controls the correctness and the scope of almost everything else in the app.
The task (validate, do not re-engineer)
Confirm at a high level that teams, membership and reporting lines match the customer's real structure: the right people in the right teams, movers reflected, and no one missing or double-counted. The highest-value CSM check is completeness - people with no team assignment, or assigned to the wrong one, distort aggregates. Large restructures, hierarchy design and bulk mapping are specialist work; capture the requirement and escalate rather than rebuilding the tree live.
How to read it
The misread is trusting a team aggregate without checking who is in the team. A team average is only meaningful if membership is complete and correct - an unassigned person silently shrinks or skews the group, and someone mapped to the wrong team moves their numbers to the wrong place. Before comparing teams or reporting a team figure, confirm the roster behind it is current, especially after reorganisations, which also break period-over-period trends if membership changed mid-window.
Honest limits
This is an admin screen; sync with an external HR or identity source, hierarchy depth and bulk operations must be confirmed with product. The org structure governs grouping and visibility, not behaviour - a correct tree does not make numbers good, it makes them attributable to the right group. Who can see what sits alongside this in privacy and access; this screen is about structure, that one about permission.
Interpretation check
A team aggregate is only as trustworthy as the org mapping behind it. Missing or misassigned people silently distort rollups and break trends when membership changes mid-period.
Practical task
In the demo, describe how you would spot-check a team's membership against the customer's real structure, and write the one completeness risk (unassigned or misassigned people) you would confirm before trusting its aggregates.
Self-check
Before reporting a team utilisation figure, what structural check matters most?
That team membership is complete and correct - no unassigned or misassigned people. The aggregate is only meaningful if the roster behind it is right.
A team's trend jumps the month of a reorganisation. What might explain it?
Membership changed mid-window, so the group is not the same before and after. The jump can be structural, not behavioural. Confirm the roster across the period.
Someone is missing from any team. Why does it matter here?
They vanish from or skew aggregates and no manager owns their numbers. Completeness of mapping is the core correctness check.
A customer needs a large hierarchy rebuild. What is the CSM move?
Validate the requirement and escalate the bulk mapping or restructure to a specialist. CSM validates fit; deep org engineering is specialist work.
Verified vs demo. Screen is live in the demo at /#/org; exact controls and figures are SME-validation-pending.