Time and Activity: Daily operations
Objective. Open the daily operations view, pick one team, and state in one sentence what happened to yesterday's paid hours and where a lead should look today.
This is the morning start screen. It answers the operations lead's first question of the day: of the hours we paid for yesterday, who was present, how much time was available, and which teams or people need a look today.
See it in the demo
What this screen answers
A team lead or ops manager opens this first thing. The question is practical and daily: of the hours we paid this team for, how many were available, and where should attention go today? It is the triage layer above the detailed attendance, utilisation and exception screens - a single place to see the shape of the day before drilling in.
The task
Set the scope to one team and the period to the most recent completed day, then read the day at a glance before drilling. The move is: start at the team level, spot the outlier (a low available-hours figure, a missing attendance, an idle or overtime flag), then open that one case rather than reading every person. Do not start from an individual - start from the team and let the screen route you.
How to read it
Hold three different quantities apart. Present / attendance is 'did they show up for scheduled time'. Available hours is 'present and able to do work' after absence, late starts and long breaks come out. Utilisation is productive activity over those available hours. The classic daily misread is treating a healthy headcount or attendance figure as proof the hours were productive - it is not. Each number has its own denominator; name it before you repeat it to a customer.
Honest limits
This screen tells you where to look, not what the answer is. A flag is a prompt to investigate against agreed rules, never a verdict on a person. It also does not prove output - a team can look clean here and still be behind on work, which is a Work Output question. Confirm with product which attendance and activity sources feed the day, and set the exception thresholds against the customer's own policy, not demo defaults.
Interpretation check
A good-looking daily summary - full attendance, no flags - is not evidence the paid hours produced work. Attendance, available hours and utilisation are three different measures with three different denominators; this screen is a triage view, not a productivity verdict.
In the field
KnackGlobal (~6,000 RCM seats): a per-team daily triage lets leads act on the few exceptions each morning across thousands of seats, framed as capacity visibility rather than monitoring in a ProHance-displacement setting.
Practical task
On the cited demo team, produce a one-line daily finding: name the team, the single outlier you would drill, and which of attendance / available hours / utilisation it concerns - without claiming it proves output.
Self-check
Why start at the team level rather than opening a person?
The screen is a triage layer - it routes finite attention to the outliers. Starting from one person wastes the view; you read every case instead of the few that fall outside the rules.
A lead says 'attendance was full, so yesterday was a good day.' What do you add?
Full attendance means people were present for scheduled time; it says nothing about available hours after breaks, utilisation, or work produced. Those are separate measures with separate denominators.
What turns this screen from data into a routine?
A named owner who opens it at a set time, drills the flagged cases, and logs a decision. Adoption is the daily review, not the login.
Verified vs demo. Screen is live in the demo at /#/daily; exact controls and figures are SME-validation-pending.