Time and Activity - CSM Adoption Playbook
Objective. Run a repeatable adoption play for Time and Activity: define what 'adopted' means for this app, stage the rollout from pilot to scale, counter the predictable risks, and install a manager review routine measured against a customer-owned baseline.
Adoption of Time and Activity is not a login count - it is a manager review routine that runs on a cadence and ends in logged actions. This playbook turns the app's own value model (available hours, exceptions, follow-through) into a staged rollout you can start with a real account this month, with the risks named up front and the success measures taken from the app's grounding rather than invented.
See it in the demo
The adoption goal and what 'adopted' looks like
The goal is simple to state and easy to fake: a manager stops reconciling attendance by hand and starts working a routed exception queue to a decision. 'Logged in' or 'dashboards opened' is not adoption. Adopted looks like a named owner working the exceptions view on an agreed cadence, drilling the few cases that matter, and logging a decision - reviewed, actioned, or dismissed as expected - every time.
Tie this back to the app's value triad before you start: recovered reconciliation effort, an exception review rate that is actually happening, and manager follow-through where reviewed cases lead to a logged action. If those three are not moving, the account has the software but not the habit. Adoption is the loop running, not the screen existing.
Staged rollout - pilot, team, scale
Stage 1 - Pilot (one team, weeks 1-2). Before any number is read, sit with the customer admin on the data sources view and the productivity rules view to agree two things: the utilisation denominator (what counts as available hours) and the exception thresholds against the customer's own policy. Milestone: one team's available-hours definition and exception rules are agreed in writing, and coverage for that team is validated as complete.
Stage 2 - Team routine (weeks 3-6). Install the manager review routine for that one team: who opens the exception queue, how often, and where the resulting action is logged. Walk one real day's timeline together so the manager can separate absent time, available hours and overtime out loud. Milestone: the manager has worked the queue to a logged decision at least twice without you driving it.
Stage 3 - Scale (weeks 7+). Replicate the agreed denominator, rules and routine to the next teams, validating coverage each time rather than assuming it carries over. Milestone: more than one manager is running the routine independently and the reconciliation chore has measurably shrunk. Do not scale a routine that is not yet self-sustaining on the pilot team.
Top adoption risks and how to counter them
Risk: it is heard as surveillance and staff resist. Counter by leading with the privacy and access screen and an employee-communication plan during onboarding; frame the app as availability and exception visibility, not keystroke monitoring. Capture-policy specifics go to product, never claimed from the demo.
Risk: numbers are disputed because the denominator or rules were never agreed. Counter by making Stage 1 non-negotiable - no reading before the available-hours denominator and thresholds are agreed and coverage is validated.
Risk: the queue is treated as a list of wrongdoers. Counter by teaching that an exception is a prompt to investigate against an agreed rule, not a verdict; coverage gaps cause false positives.
Risk: utilisation is sold internally as 'productivity'. Counter early - utilisation is activity against available hours, not output; route the output question to Work Output.
Risk: the routine fizzles after the kickoff. Counter by assigning a named owner and a cadence, and by measuring follow-through (actions logged), not flag volume or logins.
Success metrics and review cadence
Use the app's own candidate measures, framed as a baseline the customer owns, never as a vendor promise:
- Attendance reconciliation effort - hours per week team leads spend assembling the picture by hand. Target direction: toward zero once the view is trusted. Capture the starting figure in Stage 1 so there is a before.
- Exception review rate - the share of flagged exceptions a manager actually reviews each week. This is the pulse of the routine.
- Manager follow-through - do reviewed exceptions result in a logged action or decision. This is the one that proves value; a high review rate with no actions is theatre.
Review cadence: a weekly internal check during the pilot on whether the routine ran, and a monthly review with the customer on the three measures and what actions they drove. Do not promise a utilisation uplift percentage - the honest value is 'you now see available time and act on exceptions you could not see before', and the customer sets the target from their own baseline.
First month, concretely
A runnable first 30 days on a real account:
- Week 1: agree data sources, utilisation denominator and exception thresholds with the admin; validate coverage for one team; capture the reconciliation-effort baseline.
- Week 2: walk one real day's timeline with the manager (absent vs available vs overtime), agree who owns the exception queue and where actions are logged.
- Week 3: manager works the queue live with you once, logging decisions as investigation not verdict.
- Week 4: manager runs it unaided; you review the three measures and book the monthly customer review.
If coverage is weak for the scope you care about, that is the finding for the month and interpretation waits - a routine built on a distorted denominator will lose the customer's trust the first time a figure is disputed.
Interpretation check
Adoption is the manager review routine running to logged actions on a cadence, not logins or dashboard views. The success measures are reconciliation effort, exception review rate and follow-through against the customer's own baseline - never a promised utilisation uplift.
In the field
KnackGlobal (~6,000 RCM seats): at that scale a manager cannot read every timeline, so adoption hinges entirely on the routed exception queue running daily per team with logged follow-through. Framed as capacity visibility in a ProHance-displacement context, the routine - not a utilisation promise - is what makes daily review feasible and keeps the account's trust.
Practical task
For a real assigned account, write a one-page 30-day adoption plan for Time and Activity: name the pilot team, the owner of the exception queue, the agreed cadence and where actions are logged, the three baseline measures with their starting values, and the two highest adoption risks for this specific customer with your counter for each. Mark any capture-policy item you must take to product rather than assert.
Self-check
A customer reports 90% of managers log in weekly and calls the app adopted. Is it?
Not on its own. Logins are not adoption. Adoption is managers working the exception queue to logged decisions on a cadence; measure follow-through (actions logged), not login or view counts.
What must be agreed in the pilot stage before any number is read?
The utilisation denominator (what counts as available hours) and the exception thresholds against the customer's own policy, plus validated coverage for the pilot team. Reading before these are agreed makes every figure disputable.
Which single measure best proves the app is delivering value?
Manager follow-through - reviewed exceptions that lead to a logged action or decision. A high review rate with no resulting actions is activity without outcome.
A manager treats the exception queue as a list of people to discipline. What is the adoption risk and the counter?
It erodes trust and invites resistance. Reframe each item as a prompt to investigate against an agreed rule, not a verdict; note that coverage gaps produce false positives, so cases are checked, not judged, before any conversation.
Why should you not scale the routine from the pilot team to others immediately?
Because coverage and rule fit must be re-validated per team, and the routine should be self-sustaining on the pilot first. Scaling a routine nobody owns, on an unvalidated denominator, just multiplies disputes.
Verified vs demo. The views, the exception/attendance/utilisation model and the denominator distinction are demo-shown. The specific data sources, capture policy, retention and entitlements for a given customer must be confirmed with product. The success measures are a customer-owned baseline, not vendor-guaranteed outcomes.