Implementation literacy and validation
Objective. Explain the implementation chain - collection, mappings, standards, permissions and data checks - well enough to validate it and triage missing data, and recognise where it stops being a CSM job and becomes a specialist escalation.
You do not have to configure the platform, but you must be able to read whether an implementation is trustworthy. If capture coverage is partial, a mapping is wrong, a standard is unset or permissions leak, every metric the customer sees is quietly wrong - and you will be the one explaining it in a QBR. This lesson makes you literate enough to validate and to triage, and clear about the escalation boundary.
See it in the demo
The customer problem
A customer turns the product on, opens a dashboard, and sees a number that looks wrong - utilisation at 40%, output lower than they know they produced, a team missing. Their instinct is 'the tool is broken', and if you cannot diagnose it, trust collapses in week two. Almost always the cause is upstream: an agent is not deployed on some machines so capture is partial; a process or client is not mapped so its work is uncounted; a standard (expected handle time, target output) was never set so attainment is meaningless; or the wrong people can see the wrong data. None of these are bugs - they are implementation gaps. Business impact: a customer who distrusts the data stops using it, and an unused product does not renew.
How Time Champ addresses it - the chain to validate
Walk the chain in order. (1) Collection: Employee Monitoring shows agent/data coverage - which machines and people are actually reporting, and the capture policy and agent modes. Partial coverage is the single most common silent error. (2) Mappings: Work Output counts work by process, client and transaction type; if a process or client is unmapped, its work simply is not counted. (3) Standards: Work Output carries standards, complexity, targets and quality definitions; without a trusted standard, 'attainment' and 'cost per clean unit' are not meaningful. (4) Permissions: Organisation and access scope governs who sees whom; wrong scope is both a trust and a privacy problem. (5) Data checks: before interpreting any metric, check freshness and completeness. Use the demo Employee Monitoring overview to see coverage, and Work Output People and Transactions to see mappings and counted-work coverage.
What to say / do - readiness checklist and missing-data triage
Build a readiness checklist you run on every new account: Is agent/data coverage at the agreed level for every team in scope? Are all in-scope processes and clients mapped? Are standards set and marked trusted for the work you will report on? Do access scopes match the org - managers see their teams, not others? Is the data fresh to the agreed cadence? For triage when a number looks wrong, ask in this order: definition -> scope -> coverage -> mapping -> standard -> freshness (this is the discipline C05 goes deep on). Example talk track: 'Before we read this utilisation figure, let me confirm the denominator and that every machine in this team is reporting - two agents are offline, so this is 92% of the team, not all of it.' Naming the gap out loud builds trust; hiding it destroys it.
Recognise the escalation boundary
CSM depth is practical for your assigned account scope; advanced setup is a specialist job. You validate that coverage, mappings, standards and permissions are correct and triage what is missing - you do not re-architect capture policy, build new integrations, or change productivity classification rules at scale. When triage finds a gap that needs configuration beyond the customer's admin screens, or a capture-policy or integration decision, that is a specialist/product escalation, and you log it with evidence (which teams, which processes, what you observed) rather than attempting it. Knowing where your literacy ends is part of the competence - a CSM who guesses at capture-policy config can make the data worse.
Objections and honest limits
'The numbers are wrong, the tool doesn't work' - reframe calmly: the tool reports what it is fed; let us walk coverage and mappings before we conclude anything. 'Why do I have to set standards, can't it just know?' - a standard encodes the customer's own definition of expected work and acceptable quality; the tool cannot invent the customer's business rules. Honest limits: which integrations and capture modes are available in the customer's production entitlement is not something you assert from the demo - confirm with product. A non-productive application label in Employee Monitoring is not proof an employee did no useful work; it is an input to investigate, not a verdict. The recovery/output numbers are only as trustworthy as the coverage and standards beneath them.
Interpretation check
Partial capture coverage and unmapped work do not show up as errors - they show up as plausible-looking numbers that are quietly incomplete. Validate the inputs before you ever defend the outputs.
In the field
For KnackGlobal's RCM work, cost per claim is only credible if every billing/denial process is mapped and agent coverage spans the in-scope teams; a single unmapped denial queue would understate work and distort the displacement case against ProHance.
Practical task
From a seeded or demo account, produce a readiness checklist with pass/fail/unknown for each of: collection coverage, process/client mappings, standards and quality definitions, access scopes, data freshness. Then write a missing-data triage note for one failing item: what you observed, the likely upstream cause, and whether it is a customer-admin fix, a CSM action or a specialist escalation.
Self-check
A customer's utilisation looks suspiciously low across one team. Give the first three things you check and in what order.
Definition/denominator (what counts as available time), then collection coverage (are all machines/people in that team reporting), then mappings (is their work type mapped so it is counted). Low utilisation is as often a coverage or mapping gap as a real result.
Why is reporting 'cost per clean unit' before standards are set a mistake?
Without a trusted standard and quality definition, 'clean' and 'expected' are undefined, so the ratio has no meaning. You would be presenting a number the customer cannot trust or act on.
Triage finds that the customer needs capture-policy and a new integration configured. Is that a CSM task?
No. That is beyond practical account-scope literacy - it is a specialist/product escalation. You log it with evidence (teams, processes, what you observed) and hand it over, rather than attempting setup that could corrupt the data.
A manager sees another team's data. Why is this both a trust and a compliance issue, not just a config nit?
Wrong access scope exposes people's data to the wrong viewers (a privacy problem) and makes managers distrust the whole deployment. Access scope is part of the readiness checklist, not an afterthought.
Verified vs demo. The chain and screens (coverage, mappings, standards, people, attendance) are demo-shown. Exactly which capture modes, integrations and permission models exist in a given production entitlement is not demo-verified - confirm with product.