Employee Monitoring - Data and Setup Reference
Objective. Explain, at app-logic level, what Employee Monitoring needs to produce correct numbers: the signals it captures, the setup and policy it depends on, how other apps rely on it, and the exact things a CSM validates before trusting a figure - with security and entitlement specifics marked 'confirm with product'.
Employee Monitoring is the capture layer under the platform, so the quality of its numbers is decided by setup, not by the dashboards. This reference lists the signals it depends on, the configuration and policy choices that make those signals meaningful (capture policy and agent modes, classifications, away reason codes, organisation scope), the downstream apps that read from it, and the validation a CSM must do before anyone interprets a number. Where specifics touch security, retention or packaging, the honest answer is 'confirm with product'.
See it in the demo
The signals the app depends on
Everything in Employee Monitoring derives from a small set of captured signals, collected by an agent on the employee's device under a capture policy:
- Application and website activity - which apps and sites were in use and for how long. This is the raw material for the productive / non-productive / neutral split and the Top Websites & Applications view.
- Active vs idle time - captured keyboard/mouse activity versus captured inactivity. Idle is measured inactivity, and it is distinct from away time.
- Away time with reason codes - time off the system attributed to reasons (Client Call, Meeting, KT, Lunch, Tea Break, Testing). Reason codes are what separate legitimate away-from-keyboard work from idle.
- Presence signals - start time, last-seen, tracked-or-not, late, on-leave.
- Optional capture - screenshots and deeper monitoring where the customer's policy and plan allow (confirm availability with product).
Every one of these is a seeded demo value in the lab. In production each depends on the agent actually running and on the policy permitting that capture - a missing agent or a policy that excludes a capture means the signal is simply absent, not zero.
Setup and configuration that makes the signals mean something
Raw signals are not yet evidence. Four configuration choices turn them into numbers a customer can act on - describe these at app-logic level and send specifics to the implementation specialist:
- Capture policy and agent modes. What is collected, for whom, and in which mode is an administered decision, not a blanket switch. The RCM capture policy with agent modes is visible in the navigation. The exact modes, what each captures, retention periods and access scope are confirm with product and depend on plan and jurisdiction.
- Classifications. Application and site usage is mapped to productive / non-productive / neutral against the customer's own tool list. Defaults will mislabel domain tools, so this mapping is set up and reviewed per customer. The label is a configurable classification, never a built-in verdict.
- Healthy / over / under bands and away reason codes. The Productivity Split bands and the away-time reason codes are customer-configured; do not quote the demo's bands or codes as product defaults.
- Organisation and access scope. Teams, managers and who can see what are set against the customer's structure and policy (this is the F05 organisation-and-access concern). Access scope is a security matter - confirm specifics with product/security, never assert them.
Integrations (for example pulling the org structure or feeding the activity data onward) exist at app-logic level; the available connectors, directions and auth for a given customer are confirm with product.
Dependencies on other apps
Employee Monitoring is a source, not an island. Its activity feed is read by other Productivity Intelligence applications, so its setup quality propagates:
- Time and Activity reads presence, available time and utilisation from the same capture - if monitoring coverage is patchy, Time and Activity's attendance and utilisation understate reality in exactly the same way.
- Work Output contrasts activity and utilisation with completed work; it relies on the activity layer being trustworthy to make the 'busy but producing?' comparison honestly.
- Work Understanding uses activity and session signals to discover process and friction.
The practical consequence: a coverage or classification problem in Employee Monitoring is not contained to its own screens - it silently biases every downstream metric. When a downstream number looks wrong, the capture layer is a first place to look. Employee Monitoring can stand alone for a visibility use case, but when it feeds other apps its data hygiene becomes their data hygiene.
What a CSM validates before trusting the numbers
Run this validation before interpreting anything, and escalate the items marked for the specialist:
- Coverage - agents deployed and reporting for the in-scope population. Read the Team-vs-Tracked gap first; an unreported seat is a hole in every total. Identify and explain every gap (off, not installed, offline, on leave, working off-agent).
- Classifications - the productive / non-productive / neutral mapping reviewed with the customer against their real tools, with domain tools correctly labelled.
- Capture policy and access - which agent mode is in use, what is collected, retention, and who can see what, checked against the customer's policy and jurisdiction. Escalate the specifics to the implementation specialist / product / security - never assert capture, retention or access behaviour from memory.
- Away reason codes and bands - confirm the customer's real reason codes and healthy bands rather than quoting the demo's.
- Employee communication - confirm employees were told in writing what is captured and why; this is a data-trust and adoption dependency.
- Freshness and timezone - confirm last-seen freshness and the timezone the screen is reading in before comparing people or periods.
What the CSM can decide locally: coverage closure, classification review, routine scope. What always escalates: capture-mode behaviour, retention, access-control and any compliance or jurisdictional specifics.
Interpretation check
A number in Employee Monitoring is only as trustworthy as its setup: coverage decides whether the data represents the whole team, classifications decide whether the labels mean anything, and capture policy decides what exists at all. Validate setup before interpreting, and send capture-mode, retention and access specifics to product rather than asserting them.
In the field
KnackGlobal RCM: the setup that matters is complete agent coverage across distributed teams and classifications that label clearinghouse and payer portals as productive work - get those wrong and the output-per-FTE story that displaces the incumbent reads as a false negative.
Practical task
For a seeded or live account, produce a one-page setup-validation sheet: current coverage (Team vs Tracked with every gap explained), classification review status with any domain tools you corrected, the away reason codes and bands confirmed against the customer's real config, the employee-communication status, and a short escalation list of every capture/retention/access question you are sending to product. Mark each line 'validated locally' or 'escalated'.
Self-check
What are the two configuration choices that turn raw application activity into meaningful numbers, and why do both matter?
Classifications (mapping apps/sites to productive/non-productive/neutral against the customer's own tools, so labels mean something) and capture policy with agent modes (deciding what is collected, for whom, in which mode, so the data has boundaries and is defensible). Without classifications the labels are noise; without policy the deployment is surveillance.
A downstream Work Output figure looks wrong. Why is Employee Monitoring setup a first place to check?
Because Work Output and Time and Activity read from the same activity feed. A coverage gap or a bad classification in Employee Monitoring silently biases every downstream metric, so capture coverage and classification accuracy are prime suspects before the downstream app's own logic.
A customer asks exactly what each agent mode captures and how long it is retained. What is the correct CSM response?
Confirm with product. Capture-mode behaviour, retention and access controls are plan- and jurisdiction-dependent and are a security matter - describe the model (capture is policy-governed) but escalate the specifics to the implementation specialist and never assert them from memory.
Why is confirming employee communication part of data setup and not just change management?
Because it is a data-trust and adoption dependency: a deployment employees were not told about honestly produces adversarial behaviour (working off-agent, mistrust) that degrades coverage and data quality, and it is not defensible. Honest communication is part of making the numbers trustworthy.
List two things a CSM can decide locally and two that always escalate.
Local: closing coverage gaps and reviewing classifications (also routine scope, freshness/timezone checks). Escalate: capture-mode behaviour and retention, and access-control or jurisdictional/compliance specifics - these are product/security decisions, never asserted by the CSM.
Verified vs demo. The signals, navigation areas, classifications concept and the presence of RCM capture policy with agent modes are demo-shown; exact capture modes, retention, access controls, integrations and bands are customer-configured and confirm-with-product. All demo values are seeded.