Employee Monitoring - Troubleshooting and Escalation
Objective. Give the CSM a symptom-first guide to the problems that actually arise on Employee Monitoring - numbers wrong or missing, coverage gaps, a disputed figure - with the likely cause, the first checks to run, and the point at which it escalates to the implementation specialist, product or security.
Most Employee Monitoring support calls are not product faults; they are setup, coverage or interpretation problems that look like faults. This guide is organised by what the customer reports, because that is what you hear first. For each symptom it gives the likely cause, the first checks a CSM runs (described at app-logic level, no invented error strings or UI paths), and the clear escalation line - never guess on capture, retention, access or compliance.
See it in the demo
Symptom - 'The numbers look wrong or are missing'
Likely cause (in order): a coverage gap (agents off, not installed or offline), stale or wrong-timezone data, a classification problem that makes the split look nonsensical, or the capture simply not being part of the policy so the signal does not exist.
First checks a CSM runs:
- Read coverage (Team vs Tracked). If Tracked is low, the numbers are not wrong - they are incomplete. Identify which seats are not reporting and why (off, not installed, offline, on leave, working off-agent).
- Check freshness and timezone - a stale last-seen or a screen reading in the wrong timezone explains many 'missing today' reports.
- If a split looks absurd (a core tool in non-productive), check the classification mapping rather than the data.
- Confirm the capture in question is actually enabled in the policy - a signal that was never collected reads as missing, not as zero.
Escalate when: the agent is deployed and online but still not reporting (a capture/agent fault, not a config gap), or the question is whether a capture mode or retention setting is behaving correctly - that is a product/implementation matter, not a guess.
Symptom - 'Coverage gaps / people are missing from the data'
Likely cause: agents not deployed to some seats, agents disabled or offline, people working in systems the agent does not see (off-agent work), new joiners not yet provisioned, or scope/organisation mapping that excludes a team.
First checks a CSM runs:
- Quantify the gap precisely from Team vs Tracked and list the specific unreported seats.
- Bucket each gap: not installed, installed-but-off, offline, on leave, or genuinely off-agent work. The bucket decides the fix.
- For not-installed / not-provisioned, this is a deployment task - coordinate the rollout to those seats.
- For off-agent work, this is a scope and expectations conversation, not a fault - document which work legitimately happens off-agent so downstream reads are not misinterpreted.
- Re-read coverage after each fix; do not interpret any average until the gap is closed or explained.
Escalate when: agents are correctly deployed and online but a population still does not appear (agent/platform fault), or when closing the gap touches device policy, imaging or endpoint management that sits with the customer's IT and the implementation specialist.
Symptom - 'The customer disputes a figure'
Likely cause: the figure is being read as a verdict rather than a signal, coverage was not stated so the denominator is contested, away time is being conflated with idle, a seeded demo number is being compared against production expectation, or a classification is genuinely wrong for this customer.
First checks a CSM runs:
- Establish the denominator first - state coverage (Team vs Tracked) before defending any average. Many disputes dissolve once the coverage caveat is on the table.
- Confirm what the figure actually measures. If it is a non-productive percentage, name it as a configurable classification, not a judgement; if it is away time, separate it from idle via the reason codes.
- Check whether the disputed classification is in fact mis-set for this customer - if so, the customer is right and the fix is a classification review, not a defence of the number.
- Confirm the customer is not comparing a seeded demo value to their reality.
- Reframe from verdict to evidence: the figure is a prompt to investigate with context, and you investigate it together.
Escalate when: the dispute is about whether capture, retention or access is compliant or contractually correct - that always goes to product/security; never assert a compliance position to resolve a dispute.
Symptom - 'Managers are acting on flags unfairly' (the trust-breaking symptom)
This is the most dangerous symptom because it is cultural, not technical, and one incident can end adoption. Likely cause: no agreed investigation workflow, or managers trained to read labels as verdicts.
First checks and actions a CSM runs:
- Confirm whether an agreed workflow exists and is being followed - a flag should trigger investigation with context (Activity, and Monitoring where policy allows), never an action off a single screen.
- Re-teach the signature guardrail: captured activity and classifications are signals, never proof of a person's worth; a label is a prompt to look, not a conclusion.
- Check whether the trigger was actually a setup problem (bad classification, coverage gap) rather than real behaviour - often it was.
- Reinstate the action log so every flag-to-action has a recorded investigation step.
- Confirm the employee communication is in place; adversarial manager behaviour often tracks back to employees never having been told honestly what is captured and why.
Escalate when: the situation has created an HR, legal or compliance exposure - that is beyond the CSM remit and goes to the customer's own functions and to product/security on the Time Champ side.
Interpretation check
Most 'the product is wrong' reports are coverage, freshness, classification or interpretation problems, not faults. Read coverage first, confirm what the figure measures, check the classification, and only escalate a genuine agent/platform fault or any capture/retention/access/compliance question - never guess on those.
In the field
KnackGlobal RCM: the realistic trouble ticket is a payer-portal classification mis-set as non-productive feeding a disputed output figure - diagnosed as a classification problem, not a product fault, and fixed by a classification review rather than by defending the number.
Practical task
Take three seeded 'something looks wrong' reports (one missing-numbers, one coverage-gap, one disputed-figure) and for each write the likely cause, your first two checks, and the exact point at which you would escalate and to whom. Then mark which of the three, if mishandled, could damage trust most, and write the one sentence you would say to keep it from becoming an unfair action.
Self-check
A customer says today's totals are missing for a team. What is your first check and why?
Coverage (Team vs Tracked) plus freshness and timezone. Low Tracked or stale/wrong-timezone data means the numbers are incomplete, not wrong - you identify which seats are not reporting and why before treating it as a fault.
When does a coverage gap stop being a CSM config task and become an escalation?
When agents are correctly deployed and online but a population still does not appear (an agent/platform fault), or when closing the gap touches device imaging, endpoint management or policy that sits with the customer's IT and the implementation specialist.
A customer disputes a non-productive percentage. Give the first two moves.
State coverage first to settle the denominator, then name the figure as a configurable classification rather than a judgement - and check whether the classification is in fact mis-set for this customer, in which case they are right and the fix is a classification review.
Managers are disciplining people off single flags. Why is this the most dangerous symptom, and what do you do first?
Because it is cultural and one unfair incident can end adoption. First confirm whether an agreed investigation-with-context workflow exists and reinstate it, re-teach that a flag is a signal not a verdict, and check whether the trigger was actually a setup problem rather than real behaviour.
A dispute turns on whether the retention setting is compliant. How do you resolve it?
You do not resolve it yourself. Capture, retention, access and compliance questions always escalate to product/security - never assert a compliance position to win a dispute.
Verified vs demo. The diagnostic signals (coverage, freshness, classification, away vs idle) are demo-shown on the Overview; this module intentionally invents no error messages or UI paths. Capture-mode, retention, access and compliance behaviour are confirm-with-product/security. Demo figures are seeded.