Organization and workforce master
Objective. Explain the shared organisation and workforce model that every application reads from - organisation, teams, people, skills, process and client - so you can size a deal to the right boundary and know that correct metrics depend on a correct master.
Almost every 'the numbers are wrong' complaint traces back to how the organisation and workforce are modelled. This teaches the shape of that shared master, why it is the denominator and boundary for every metric, and the CSM discipline of validating it before anyone trusts a dashboard.
See it in the demo
What the organisation and workforce master is in Time Champ terms
Across the twelve applications a customer is modelled once as an organisation that contains teams and people, with attributes like skills and tenure, and with work attributed to processes and clients. Every application reads from this shared shape. You can see it directly: Work Output organises around people, 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.
Two dimensions of this master drive almost everything downstream (the F05 model): WHO - organisation to team to person, plus skills and tenure, which is the denominator for activity and utilisation metrics; and WHAT AND FOR WHOM - process, client, payer and work type, which is the boundary for output and outcome metrics. Get the master right and the same screen correctly tells a team leader, a site head and an executive a different story because scope is applied, not because the data differs.
What a Sales or CSM person can say confidently
Safe to say to a buyer sizing a deal: 'We model your organisation once - teams, people, skills, process and client - and every application reads from that, so you do not re-key your structure per tool.' This is both true and a strong simplicity message.
Safe to say for scoping (S03): 'Let us model one site and one process correctly first. A clean, small master gives you trustworthy numbers fast, and we expand from a proven base.' The master turns scoping into de-risking.
Safe for CSM: before the first dashboard review, walk the organisation tree with the administrator - right people in the right team, nobody double-counted, decommissioned clients and queues excluded. A thirty-minute master validation prevents months of metric disputes (C02, C05).
Do not assert exact import mechanisms, directory-sync automation, or how the master stays in step with the customer's HR system - those are configuration and integration specifics.
What always escalates to security or product
Route to a specialist:
- How the workforce master is loaded and kept current (manual, file, directory sync, HRIS integration) for a specific customer.
- Field-level detail: which attributes are mandatory, how movers and re-orgs are handled automatically, how historical structure is retained for period-over-period comparison.
- Data residency and access to the master data itself (that is a PLAT-06 security question).
- Any contractual commitment about synchronisation frequency or accuracy.
The honest posture: you can confidently describe the SHAPE of the model because the demos show it; you escalate the MECHANICS of how a given customer's master is populated and maintained.
The honest limit
Demo-supported: a customer is modelled as organisation/team/person with skills and tenure, and work is attributed to process and client, and every application reads from that shared shape.
Confirm with product: the exact import/sync mechanism, the HRIS or directory integration, mandatory fields, automated handling of re-orgs and movers, and historical-structure retention for a specific customer.
Separate cleanly: 'the platform is organised around a shared workforce and organisation master' (safe) from 'your master will sync automatically from your HR system every night' (confirm with product). The second is a real question with a real answer - just not yours to give on the call.
Interpretation check
A metric is only meaningful inside its modelled boundary; the organisation and workforce master is the denominator and boundary for every number, so a wrongly modelled master makes an authoritative-looking figure quietly false. Validate the master before interpreting the metric.
In the field
In a ~6,000-seat account like KnackGlobal, fair output-per-FTE and cost-per-claim comparisons depend entirely on the master being correct - so the CSM validates teams, tenure and client/payer boundaries before any displacement comparison is shown.
Practical task
Using the Work Output and Time and Activity demos, draw the shared master for a sample account: organisation to teams to people (with skills/tenure) and the process/client boundary. Mark which population and boundary facts you would validate at onboarding, and which mechanics (sync, import, retention) you would route to a specialist.
Self-check
Why is the organisation and workforce master the first thing a CSM validates?
Because it is the denominator for activity/utilisation metrics and the boundary for output/outcome metrics; if teams, people, skills, process or client are modelled wrongly, every downstream number looks authoritative but can be false.
A buyer worries about re-keying their org structure into each tool. What is the true, reassuring answer?
The organisation is modelled once - teams, people, skills, process, client - and every application reads from that shared master, so structure is not re-entered per application.
A customer asks whether the master syncs automatically from their HRIS every night. What do you do?
Confirm the shared-master shape, then route the exact import/sync mechanism and frequency to a specialist - do not commit to automated nightly sync you have not verified.
Which parts are demo-supported versus confirm-with-product?
Demo-supported: the org/team/person/skills/process/client shape read by every app. Confirm-with-product: the import/sync mechanism, HRIS integration, mandatory fields, mover/re-org automation and historical retention for a given customer.
Verified vs demo. The shared organisation/team/person/skills/process/client model read by every application is shown in the demos; the import/sync mechanism, HRIS/directory integration and historical-structure retention for a specific customer are product facts to confirm.