Time and Activity - Data and Setup Reference
Objective. Know what Time and Activity needs to produce correct numbers: the signals it depends on, the configuration that gives its labels meaning, its dependencies on other apps, and the specific things a CSM validates before trusting a figure versus escalates to the implementation specialist.
Every attendance and utilisation figure in this app rests on two foundations: the signals feeding it (coverage and freshness) and the rules that classify those signals (the denominator and the thresholds). This reference maps both at app-logic level so a CSM can validate trust before interpreting, and a Sales rep can speak to setup honestly without over-claiming. Exact connectors, capture policy and retention are confirm-with-product.
See it in the demo
The signals the app depends on
Time and Activity reconciles two kinds of input into a structured view of the paid hour: attendance signals (presence against schedule - who was there and when) and activity signals (what the captured activity was, used to classify time as productive, idle or on break). From these it derives present time, available hours, utilisation, idle, overtime and exceptions.
The decisive property of these signals is coverage and freshness. A person with no signal is not read as idle or absent - the gap silently distorts the shared denominator, so utilisation can be over- or under-stated depending on how the gap falls. Read every figure as 'for the covered population, as of this freshness'. Which specific attendance and activity sources are in scope for a customer, and exactly what is captured, must be confirmed with product - the demo shows the model, not an entitlement.
The setup and configuration that gives numbers meaning
Two configuration layers decide what the dashboards actually say, described here at app-logic level (exact options and controls: confirm with product):
- The utilisation denominator. Utilisation is productive activity over a base, and that base can be available hours or scheduled hours. The same activity gives very different percentages depending on which is configured, so the denominator must be identified and agreed, not assumed.
- Productivity rules and thresholds. These define what counts as productive, what triggers an idle or exception flag, break policy, and the overtime/after-hours windows (which depend on schedule, policy and timezone). A 'non-productive' label is a classification under these rules, not a fact about the person.
Connector configuration, mappings, capture-policy settings and retention are specialist and product work. A CSM validates that the agreed rules reflect the customer's policy; deep rule design and integration are escalations, not live tuning.
Dependencies on other apps
Time and Activity is the availability-and-use layer of the paid hour; it deliberately stops short of some questions that belong to adjacent apps:
- Employee Monitoring is where the activity-capture policy and classification context sit most deeply; Time and Activity surfaces the availability view built on top of that capture. Agent coverage and classification review often need to be validated there.
- Work Output owns the output question. Utilisation tells you available hours were engaged; it cannot tell you whether valuable work was produced. Hand the 'is the busy team actually producing?' question to Work Output.
- Value Leakage owns the capacity-to-cash conversion. The capacity-and-leakage view sizes an opportunity in hours; turning that into money, with owner and recovery tracking, is Value Leakage's job.
Time and Activity delivers standalone value (available hours and exceptions) without these, but its numbers must not be stretched to answer their questions.
What a CSM validates before trusting a number
Run this validation gate before interpreting any figure, and treat a failure here as the finding rather than pushing on:
- Coverage - which people and teams actually have a signal; flag anyone with no or stale data who would distort the denominator.
- Freshness - is the data current for the period you intend to read.
- Denominator - is utilisation against available hours or scheduled hours, and is that agreed with the customer.
- Rules and thresholds - do the productivity, idle, break and overtime definitions match the customer's policy, not demo defaults.
- Access scope - remember that a manager restricted to their org sees a different population and denominator than an admin, so two people can honestly quote different figures.
A confident number over 70% coverage is a different claim from the same number over 98% coverage - say which.
What to escalate to the implementation specialist
Hold the line between CSM validation and specialist setup. Escalate, do not improvise: connecting a new attendance or activity source; mappings and integration work; substantive changes to classification logic or category libraries; capture-policy, retention and privacy settings; and any role or access redesign. These are trust and compliance decisions, not quick toggles, and for privacy or access changes the customer's own security and HR stakeholders belong in the room.
The CSM job is to confirm the configuration reflects the customer's policy and to capture requirements clearly when it does not. For Sales, the honest posture is: 'the app needs coverage of your attendance and activity signals and an agreed definition of available hours and exceptions; the exact connectors and capture policy for your deployment we confirm with product.'
Interpretation check
Correct numbers require both complete, fresh coverage and an agreed denominator plus rules. A missing source does not read as zero - it skews the denominator - so coverage is the gate before interpretation, and classification labels are only as sound as the rules agreed with the customer.
In the field
KnackGlobal (~6,000 RCM seats): across thousands of seats a few percent of uncovered agents moves a team denominator materially, so coverage validation is the precondition for the capacity-visibility claim - the setup gate is where credibility is won or lost before any number reaches the customer.
Practical task
For one demo team, write a trust statement before interpreting any figure: state the coverage and freshness you would require, which denominator you would confirm, two rule/threshold items you would agree with the customer, and one setup item you would mark 'escalate to specialist' rather than attempt yourself.
Self-check
A team's utilisation looks suspiciously high. Which setup factors do you check first?
Coverage (are there people with no signal inflating or distorting the available-hours base), the denominator (available vs scheduled hours), and the productivity rules behind 'productive'. A data gap or a scheduled-hours denominator can produce the effect, not behaviour.
What is the difference between what a CSM validates and what they escalate?
A CSM validates that coverage, freshness, denominator, rules and access scope are correct and match the customer's policy. Connecting sources, integration, redesigning classification logic, and capture/retention/privacy settings are escalated to the implementation specialist or product.
Which adjacent app answers 'was the work actually valuable', and why can't Time and Activity?
Work Output. Time and Activity measures availability and activity use (utilisation), not completed output or quality. Utilisation can be high on low-value work, so the output question must move to Work Output.
Why is 'a missing data source reads as zero' a dangerous assumption?
Because it does not read as zero - it skews the denominator. A person with no signal distorts the available-hours base rather than showing as fully idle, so partial coverage quietly over- or under-states figures. Validate coverage before interpreting.
A Sales prospect asks exactly which sources feed the app and what is captured. What is the honest answer?
Describe the model (attendance and activity signals, coverage and freshness, an agreed available-hours denominator) and confirm the specific connectors, capture policy and entitlements with product for their deployment rather than asserting them from the demo.
Verified vs demo. The signal model, the coverage/freshness dependency, the denominator distinction and the rule-driven classification are demo-shown. Exact attendance and activity connectors, capture policy, retention, mappings and access roles for any customer must be confirmed with product.