Work Output - CSM Adoption Playbook
Objective. Run a Work Output rollout that ends in a customer managing to results: a staged pilot-to-scale plan, the adoption risks specific to an output tool, and the success metrics to watch - with the recoverable/billed/collected/capacity value separation protected at every stage so adoption is not declared on a number that cannot be defended.
This is the CSM's runnable plan for getting Work Output adopted on a real account this month. It builds on the app overview's validation routine (completion definitions, source coverage, standards, quality) and turns it into a staged rollout with a milestone at each stage, named risks and counters, and a measurable definition of 'adopted'. The through-line is that Work Output only earns adoption when a manager changes a decision because of output evidence - not when the dashboards merely light up.
See it in the demo
The adoption goal and what 'adopted' looks like
Adopted does not mean the app is live or that people have logged in. For Work Output, adopted means managers are making capacity, overtime and coaching decisions from clean output per paid hour instead of from activity and attendance - and can defend the standard and the denominator behind every figure they cite.
The honest adoption ladder for this app, worst to best:
- Entitled - the customer has Work Output in their contract.
- Configured - sources are wired, completion definitions and standards are set and agreed.
- Used - people open the screens and read the numbers.
- Routine - a recurring manager review turns on output evidence, with an action log.
- Realised - a decision changed and a measured before-and-after followed.
Most 'adoption' stalls at level 3, where the dashboards are watched but no decision moves. Your job is to pull the account to level 4 and prove level 5 at least once. Note that realisation here means a measured operational change; it does not mean cash - capacity freed is not money collected, and that line stays intact all the way up the ladder.
Staged rollout: pilot, team, scale
Stage 1 - Pilot (weeks 1-3, one process, one or two teams). Pick a process where completion is cleanly defined and the customer already feels an output question (aging claims, rework, cost pressure). Set standards and complexity bands with the customer, confirm source coverage, and run the time-to-outcome chain for that process once with the sponsor in the room. Milestone: the customer agrees the completion definition and standard in writing, and counted-work coverage for the pilot process is confirmed - no uncounted manual work hiding the real volume.
Stage 2 - Team (weeks 4-7, the full department). Extend to every team in the department and stand up the weekly manager review: read clean output per paid hour, use quadrants to decide where to look, drill a shortfall to root cause, and log one action with an owner. Milestone: two consecutive manager reviews held from Work Output evidence, each producing a logged action - not just a readout.
Stage 3 - Scale (weeks 8-12, more processes or clients). Add processes or client portfolios, each with its own agreed standards; introduce cost per clean unit into the monthly review once rates are confirmed on the customer's model. Milestone: one measured before-and-after on a pilot action (an output or quality change the customer attributes to a decision made here), framed as an operational result, with any cash claim routed to the customer's finance view rather than asserted from the app.
Top adoption risks and how to counter them
Risk 1 - Coverage gap undermines trust early. If completed work happens off-system and is not counted, the first number a manager challenges will be wrong and confidence collapses. Counter: make counted-work coverage the pilot's exit gate, not an afterthought; surface and document every known uncounted source before any figure is shown.
Risk 2 - Standards treated as set-and-forget defaults. Attainment against an arbitrary standard tells nobody anything, and a manager will feel it. Counter: make the customer own and agree each standard, matched to complexity, before attainment is reported in any review.
Risk 3 - 'This is a speed-up / surveillance tool' resistance from managers or staff. Counter: lead every review with clean output and cost per clean unit, never raw throughput; pair with the access and privacy posture so the capture boundary is explicit.
Risk 4 - Comparison trap discredits the rollout. A manager ranks teams on raw counts, reaches a wrong conclusion, and blames the tool. Counter: train the normalisation discipline (work type, complexity, period, tenure, quality) in the first team-stage review and refuse unnormalised league tables.
Risk 5 - Projection presented as result. Someone lifts an AI-impact or ROI figure into a steering deck as achieved savings. Counter: enforce the projection-versus-result line in writing; opportunity is labelled opportunity until a measured before-and-after exists.
Success metrics to watch and the review cadence
Watch the app's own candidate measures, read as an adoption signal rather than a performance score:
- Counted-work coverage - the share of real completed work actually counted. This is the foundation metric; if it drifts, stop and fix sources before trusting anything else.
- Trusted standards - how many processes have a customer-agreed, complexity-matched standard. Rising coverage here is what makes attainment defensible.
- Clean output per paid hour - the headline operating metric, read only with the quality filter on.
- Cost per clean unit - introduced once rates are confirmed on the customer's model; the figure that carries the business case.
Also track two pure-adoption signals the grounding implies: manager follow-through (actions logged and closed from reviews) and routine cadence held (reviews actually happening).
Cadence: weekly manager review (read, drill, log one action) during stages 2-3; monthly business review (coverage health, trusted-standard progress, one measured before-and-after, cost per clean unit on the customer's rates); quarterly re-validation of completion definitions and standards as the operation changes. Keep capacity value and cash in separate columns in every pack.
Interpretation check
Adoption is proven by a manager changing a decision from clean output per paid hour and defending the standard and denominator behind it - not by dashboard logins; and realisation at the top of the ladder is a measured operational change, never cash, because capacity and recoverable value stay separate from billed and collected value throughout the rollout.
In the field
KnackGlobal (RCM, ProHance displacement): the pilot process is a claims queue with a clean completion definition, the team stage stands up the weekly manager review on clean claims per paid hour, and the scale stage introduces cost per clean claim on KnackGlobal's own rates. Adoption is proven when a staffing or overtime decision is made from output evidence and a measured before-and-after follows - with the cost-per-clean-claim case carried as the displacement argument, never with recoverable opportunity presented as collected cash.
Practical task
Take one real account you own this month. Draft a one-page rollout: name the pilot process and why its completion definition is clean, write the milestone that closes each of the three stages, list the two highest adoption risks for this specific account with a counter each, and specify the weekly and monthly review agendas with the exact metrics each will read. Mark on the page where capacity value and cash are kept apart and where a projection must never be presented as a result.
Self-check
A customer says Work Output is 'fully adopted' because every manager has the dashboards open each morning. Do you agree?
No. That is level 3 (used), not adopted. Adoption requires a routine where output evidence changes a decision, with a logged, closed action - and ideally one measured before-and-after. Watching dashboards is not managing to results.
Why is counted-work coverage the exit gate for the pilot stage rather than something to tidy up later?
Because every downstream figure inherits a coverage gap. If completed work is uncounted, the first number a manager challenges is wrong and trust collapses early. Confirming coverage before any figure is shown protects the whole rollout.
At the scale stage you produce a measured before-and-after and the sponsor wants to book the improvement as savings. How do you frame it?
As an operational result - the output or quality change that was measured. Any cash figure is routed to the customer's own finance view, never asserted from the app, because capacity and recoverable value are not collected cash. Keep the value types in separate columns.
A department head wants a league table ranking teams by transactions this month to drive the rollout. What do you do?
Refuse the raw ranking and normalise first: same work type, complexity, period, tenure, and the quality filter. An unnormalised table produces a wrong conclusion that gets blamed on the tool - the comparison trap is a top adoption risk, so counter it in the first team-stage review.
Which two signals, beyond the four candidate measures, tell you adoption is actually sticking?
Manager follow-through (actions logged and closed from reviews) and routine cadence held (reviews actually happening on schedule). Both measure behaviour change, which is what distinguishes a used tool from an adopted one.
Verified vs demo. The screens that power each stage (overview, transactions, targets, cost) are demo-shown on a seeded dataset; the customer's completion definitions, source integrations, agreed standards, cost model and rates, and any realised cash figure must be confirmed with product and owned by the customer before they enter a review.