Time and Activity - Troubleshooting and Escalation
Objective. Diagnose the common Time and Activity problems a CSM meets - numbers that look wrong or missing, coverage gaps, and disputed figures - by naming the likely cause, the first checks to run, and the point at which it becomes a product or specialist escalation.
When a Time and Activity number is challenged, the fault is usually in coverage, denominator or rules rather than in the data itself. This guide is organised by symptom. For each, it gives the likely causes at app-logic level, the first checks a CSM runs before touching the vendor, and the clear line where the problem stops being a validation task and becomes an escalation. No invented error messages or UI paths.
See it in the demo
Symptom - numbers look wrong or missing
Likely causes. A figure looks implausibly high or low, or a team or person shows nothing. The usual culprits, in order: a coverage gap (someone with no signal distorting the denominator rather than reading as zero); stale data (the period you are reading is not current); the wrong denominator (utilisation against scheduled hours when you expected available hours); or a classification rule that labels time differently from how the customer works.
First checks. Open the data sources view and confirm coverage and freshness for the exact scope and period in question - is every person signalling, and is the data current? Then confirm the denominator on the attendance view and the relevant rule on the productivity rules view. Re-read the figure as 'for the covered population, as of this freshness'. A low number that coincides with a known outage or a missing source is a data problem, not a behaviour problem.
When to escalate. If coverage is genuinely incomplete because a source is not connected or a mapping is wrong, capture the gap and escalate connector and integration work to the implementation specialist - do not attempt the integration yourself.
Symptom - coverage gaps
Likely causes. People or teams with no activity signal, partial signal, or stale data. This is the most dangerous class of problem because it is silent: a gap does not read as zero, it skews shared denominators, so utilisation, idle and capacity figures all drift without any obvious error.
First checks. On the data sources view, identify exactly who is and is not covered within the scope you care about, and how current their data is. Separate 'no signal at all' (likely a connector or agent issue) from 'partial or stale signal' (possibly a freshness or intermittent-capture issue). Quantify it: a figure over 70% coverage is a materially weaker claim than the same figure over 98%, and that coverage number is itself the headline finding to report before any interpretation.
When to escalate. Connecting a new source, fixing a mapping, or diagnosing why an agent is not reporting is specialist and product work. The CSM job is to find and size the gap and hand it over with the affected scope named; validating coverage is yours, closing it is the specialist's.
Symptom - a customer disputes a figure
Likely causes. The customer says a number is 'wrong', but the figure is usually technically correct and answering a narrower question than they assume. Common roots: they read utilisation as output or productivity; they compare two figures built on different denominators; two people see different numbers because their access scope differs; or a classification label ('non-productive', 'idle') is read as a verdict on a person rather than an output of agreed rules.
First checks. Establish what question the customer thinks the number answers, then walk the paid-hour chain back to its denominator and coverage. Confirm both disputed figures use the same, agreed denominator and scope. If it is a classification dispute, open the productivity rules view and check whether the rule matches the customer's policy - a label is 'under the agreed rules', not a fact. Reframe an exception as a prompt to investigate, not a finding of fault.
When to escalate. If the dispute reveals that the agreed rules or denominator no longer fit the customer's policy and need substantive redesign, that is an escalation to product or the implementation specialist, not a live retune.
Symptom - idle, overtime or exception flags the customer calls false
Likely causes. Flags that the customer insists are wrong. Usually they are not wrong, they are under-contextualised: idle is absence of captured signal (a long call or offline work reads as idle); after-hours activity is legitimate in a flexible or multi-timezone team but flagged against a standard window; overtime is counted against a schedule that does not match reality; or an exception threshold is set to a demo default rather than the customer's policy.
First checks. For idle, check the configured idle threshold and whether the activity could be uncaptured work. For overtime and after-hours, confirm the schedule, policy and timezone behind the flag. For exceptions, confirm the threshold was agreed with the customer and that coverage is not producing a false positive (no signal read as absence). In every case, the flag is a prompt to drill, not a conclusion.
When to escalate. Timezone, schedule, break-policy and threshold configuration that needs to change substantively goes to the specialist; the CSM validates fit and captures the requirement.
The escalation line - what a CSM never guesses
Hold a firm boundary so troubleshooting never drifts into improvised setup. A CSM validates and diagnoses; a specialist changes configuration and integration. Escalate, with the affected scope and the customer requirement captured clearly: connecting or fixing attendance and activity sources; mappings and integration; substantive changes to classification logic, thresholds or category libraries; schedule, timezone and break-policy changes; and anything touching capture policy, retention, access roles or privacy - for which the customer's security and HR stakeholders belong in the room.
Never assert capture-policy or security specifics from the demo, never retune a customer's classification logic live, and never let an unresolved coverage gap pass as a trustworthy figure. When the honest output is 'here is what the evidence shows and what still needs confirming', say exactly that and route it to the owner.
Interpretation check
Most Time and Activity problems trace to coverage, denominator or rules, not to broken data. The CSM job is to run the coverage-denominator-rules checks and diagnose; connecting sources, fixing mappings and redesigning classification or policy are specialist escalations, and capture/security specifics are never guessed.
In the field
KnackGlobal (~6,000 RCM seats): at that scale a few uncovered agents can move a team denominator enough to trigger a dispute, so the first move on any challenged figure is always a coverage check before interpretation - ruling out a data gap is what keeps the capacity-visibility story credible rather than accusatory.
Practical task
Take one seeded or demo discrepancy and write an escalation-ready triage note: the symptom, the coverage/denominator/rule checks you ran and what they showed, your diagnosis (data gap, misread, or genuine configuration mismatch), and either the one-line correction for the customer or the specific requirement and scope you are escalating to the specialist.
Self-check
A team's figures look wildly off. What is the first thing you check and why?
Coverage and freshness on the data sources view for that exact scope and period. A gap does not read as zero - it skews the denominator - so an off figure is often a coverage or freshness problem, not behaviour. Report the coverage level as the finding before interpreting.
A customer insists a utilisation figure is 'just wrong.' How do you diagnose it?
Find out what question they think it answers, then walk back to its denominator and scope. Usually the figure is correct but read as output, or built on a different denominator or access scope than they assume. Confirm same denominator and scope before concluding there is an error.
An agent is flagged idle for a block the customer says was a long client call. Bug or expected?
Expected, and a classic under-contextualised flag. Idle is absence of captured signal, so an uncaptured call reads as idle. Check the idle threshold and capture, and treat the flag as a prompt to drill, not a finding.
You find three agents with no signal at all. What do you do?
Size and name the gap with the affected scope, re-state affected figures as 'covered population only', and escalate the source or agent fix to the implementation specialist. Validating coverage is the CSM job; connecting sources is not.
A dispute reveals the agreed classification rules no longer fit the customer's policy. CSM fix or escalation?
Escalation. Validating fit and capturing the requirement is the CSM job; substantive redesign of classification logic or thresholds goes to product or the implementation specialist, not a live retune.
Verified vs demo. The diagnostic model and the coverage/denominator/rule checks are demo-shown and derived from the app's workflows. Exact connectors, agent behaviour, thresholds, schedules and capture/retention settings are deployment-specific and confirm-with-product; this guide names no specific error messages or UI paths.