Organization and access scope
Objective. Understand how a customer is modelled in Time Champ - organisation structure, teams, roles and access scope - so you size a deal to the right boundary, answer 'who sees what' correctly, and spot the scope problems that quietly break metrics and adoption.
Almost every 'the numbers are wrong' complaint and every 'who can see my data' objection traces back to how the organisation and access are modelled. This teaches the shape of the customer model, why role and scope determine both trust and metric correctness, and how CSMs validate it before anyone reads a dashboard.
See it in the demo
The customer problem
A metric is only meaningful inside a boundary: this team, this site, this client, this period. When the organisation is modelled wrongly - a person in two teams, a site missing agents, a client scope that quietly includes a decommissioned queue - the numbers look authoritative and are quietly false. Separately, access scope is where the privacy promise is kept or broken: if a team leader can see another site's employee data, you have both a trust breach and a compliance exposure. The business impact is two of the most damaging things that can happen to an account: managers losing faith in the numbers because comparisons are unfair, and employees or security losing faith because the wrong people can see the wrong data. Both are rooted in modelling, and both are preventable if scope is validated before interpretation.
How the customer is modelled
Across the applications, a customer is modelled as an organisation containing teams and people, with work attributed to processes and clients, and every view governed by role and scope. You can see the shape directly in the demos: Work Output organises around people and teams, processes and clients; Time and Activity around attendance, teams and exceptions; the Workforce Management apps around skills, queues, intervals and time zones; RCM Operations around payer and client scope; RCM Insights exposes role scope and a sample role sign-in.
Two modelling dimensions drive almost everything downstream:
- Who - organisation to team to person, plus skills and tenure. This is the denominator for activity and utilisation metrics.
- What and for whom - process, client, payer, work type. This is the boundary for output and outcome metrics.
Role then determines which slice of that model a user can see and act on. The practical consequence: the same screen tells a team leader, a site head and an executive a correctly different story because scope is applied, not because the data differs.
Roles and access scope
Access is scoped by role and by position in the organisation. An administrator configures collection, mappings, standards and permissions (the C02 onboarding reality). A manager sees and acts within their team or site. An employee sees their own data and what the policy exposes. Business users in RCM Insights operate within a role scope that bounds which data a question can reach.
Why this matters commercially and operationally:
- For sales, the organisation model is how you size the smallest useful scope (S03): one site, one process, one client - not 'the whole enterprise' on day one. A tightly scoped start is both more credible and easier to prove.
- For CSM, validating role and scope is step zero of trust. Before reconciling any metric (F06, C05), confirm the denominator population and the client/process boundary are modelled correctly, and confirm that access matches the customer's intended policy.
Exact production role definitions, permission granularity and SSO/provisioning specifics vary by configuration - confirm with product rather than asserting a fixed role matrix.
What to say / do
Sales, when scoping a deal: 'Let us not boil the ocean. If we model one site and one process correctly, we get numbers you trust fast, and we expand from a proven base. What is the cleanest boundary to start with?' This turns the organisation model into a de-risking tool rather than a configuration chore.
Sales, answering access questions: 'Views are scoped by role and by where someone sits in the org - a team leader sees their team, not the site next door. The exact permission detail we will confirm with a specialist, but the shape is role-and-scope, not all-or-nothing.'
CSM onboarding routine: before the first dashboard review, walk the organisation tree with the administrator - are all people in the right team, is anyone double-counted, are decommissioned clients/queues excluded, does each role see only its intended scope? Capture gaps as a missing-data triage item (C02). A thirty-minute scope validation here prevents months of 'the numbers are wrong' disputes.
Objections and honest limits
'Can our team leaders see other teams' data?' - Access is scoped by role and org position; the honest answer is that it is designed to be bounded, with exact permission granularity confirmed with product. Do not promise a specific permission behaviour you have not verified.
'Our org changes constantly - re-orgs, new clients, movers.' - A real operational cost. Position scope maintenance as an ongoing administrator routine, and for CSMs, as something to re-validate at each business review. Stale org models are a leading cause of metric disputes.
Honest limit: the demos show that the product is modelled around organisation, teams, people, process, client and role scope, and expose role sign-in. They do not fix the exact production role matrix, permission granularity, or identity/provisioning integration for a given customer - those are configuration and product facts. Separate 'scope is a first-class concept here' (demo-supported) from 'your specific roles will behave exactly like this' (confirm with product).
Interpretation check
A metric is only meaningful inside its modelled boundary; a wrongly modelled org or scope makes an authoritative-looking number quietly false, and a wrongly scoped role is both a trust and a compliance problem. Validate the model before interpreting the number.
In the field
In a ~6,000-seat account like KnackGlobal, scope is the make-or-break: output-per-FTE and cost-per-claim comparisons are only fair once teams, tenure and client/payer boundaries are modelled correctly - so the CSM validates the org tree and client scope before any displacement comparison is shown to the customer.
Practical task
Using the Work Output and RCM Insights demos, draw the customer model for a sample account: organisation to teams to people, the process/client boundary for output, and a simple role-to-scope table (administrator, manager, employee, business user). Mark which cells you would confirm with product before stating to a customer.
Self-check
A manager insists utilisation 'must be wrong' for their team. Before touching the metric, what organisation facts do you check?
Whether the team membership is correct (right people, nobody double-counted or missing), whether the denominator population matches who should be counted, and whether any decommissioned client/queue is wrongly in or out of scope.
Why does a tightly scoped start (one site, one process) usually make a stronger sale than an enterprise-wide rollout?
A correct, small scope produces trusted numbers quickly and proves value from a clean base, which de-risks expansion; a broad rollout multiplies modelling errors and delays trustworthy numbers.
A customer asks whether a team leader can see another site's employee data. What is the responsible answer?
Views are designed to be scoped by role and org position, so a leader sees their own team rather than the site next door - with exact permission granularity confirmed with a specialist rather than promised on the call.
Which parts of the org/access model are demo-supported versus confirm-with-product?
Demo-supported: the product is modelled around org/team/person/process/client and role scope, with role sign-in shown. Confirm-with-product: the exact role matrix, permission granularity, and identity/provisioning integration for a specific customer.
Verified vs demo. The organisation/team/person/process/client model and role-scoped views (including role sign-in) are shown in the demos; the exact production role matrix, permission granularity and identity/provisioning integration need product confirmation.