Work Understanding - CSM adoption playbook
Objective. Give a CSM a runnable staged plan to take a customer from 'findings generated' to 'improvement verified', so adoption is measured by reviewed findings and measured time released - not by how many friction findings the product produced.
Work Understanding is adopted when a customer stops acting on generated findings and starts running validated before/after experiments with named owners. This playbook stages that: a pilot that confirms detection confidence and taxonomy on one process, a team stage that establishes the finding-review habit, and a scale stage where improvement experiments become a standing routine. Throughout, the adoption risk is specific to this app - a customer treating an inferred, confidence-bounded finding as proven waste - so every stage counters that with the review discipline rather than more dashboards.
The adoption goal and what 'adopted' looks like
Adopted here does not mean the customer logs in and looks at friction findings. It means a repeatable loop is running: a finding is reviewed by a human, its detection confidence and taxonomy are confirmed, it is de-duplicated against other findings, it is converted into one experiment with a named owner, and the before/after is measured against the customer's own baseline.
The honest definition of adoption for this app is: reviewed findings and measured time released, not findings generated. A customer who has 200 generated findings and zero validated experiments has not adopted - they have a backlog. A customer who has run three clean before/after experiments has adopted, even if the finding count is small.
Anchor the goal to the customer's own outcome from the success plan (for an RCM customer, usually days-in-AR or a cycle-time target), never to activity inside the tool.
Staged rollout: pilot -> team -> scale
Pilot (one process, one owner). Pick a single process where the customer already feels the pain and owns the outcome. The milestone is not 'friction found' - it is detection confidence and taxonomy confirmed on that process, and one validated finding turned into one tracked experiment with an owner. Use Work detection (/#/sessions) and Workflow discovery (/#/discovery) to confirm the observed flow matches the real process before anything rests on it.
Team (the review habit). Expand to the team that runs that process. The milestone is a standing finding-review routine: a short recurring session where new findings are reviewed, confidence and overlap are checked, and at most one or two are promoted to experiments. The win here is behavioural - the team treats findings as candidates, not instructions.
Scale (improvement as routine). Extend to more processes once the review habit holds. The milestone is a running cadence of before/after experiments with verified released time, feeding the customer's QBR. Scale the discipline, not just the screens - adding processes without the review habit just multiplies unreviewed findings.
The top adoption risks for this app and how to counter them
Risk 1 - treating inferred findings as proven waste. The product's whole honesty rule is that a discovered workflow is inferred from signal, conformance depends on the chosen reference path, and friction/rework are hypotheses, not proven waste. Counter: make the review step mandatory before any finding is acted on, and teach the owner to state a finding as 'observed contribution with a confidence, confirm with the customer'.
Risk 2 - summing overlapping findings into a savings number. The customer's instinct is to total the friction list. Counter: de-duplicate in the review session and only ever claim measured before/after on validated findings.
Risk 3 - the finding backlog. Generating more findings than the team reviews. Counter: cap the number of live experiments; promote few, finish them.
Risk 4 - automating the wrong step. Acting on the longest active step while the days sit in waiting. Counter: use Step time and waiting (/#/steps) to confirm where the elapsed time actually concentrates before proposing a change.
Risk 5 - privacy stall. Employees or a works council block the rollout. Counter: use Privacy and evidence (/#/privacy) early, confirm aggregation and access with the customer's security owner, and never overclaim capture.
The success metric to watch and the review cadence
Watch the app's own candidate measures from grounding, in this order of maturity:
- Validated work coverage - how much of the real process is observed with adequate confidence. Low coverage means findings are partial; this is the earliest health check.
- Reviewed findings - findings a human has actually examined, not just the generated count. This is the adoption signal in the team stage.
- Improvement experiments - validated findings converted into tracked before/after changes with an owner.
- Measured time released - the verified reduction after a change, against the customer's baseline. This is the outcome, and it is a result, never the modelled opportunity.
Cadence: a short weekly finding-review session (confidence, overlap, promote one or two), a monthly improvement-progress check (experiments running, released time measured), and the quarterly QBR where verified released time is tied back to the customer's business outcome. Keep opportunity estimates out of the QBR headline - report what was measured.
Run it this month with a real account
A concrete 30-day shape a CSM can start now:
- Week 1: pick one process with a willing owner; confirm detection confidence and taxonomy on it (/#/sessions, /#/taxonomy); confirm the discovered flow matches reality with the customer (/#/discovery).
- Week 2: surface friction and step-time findings (/#/friction, /#/steps); in a review session, de-duplicate, check confidence, and pick exactly one to validate.
- Week 3: set up the experiment in the improvement workspace (/#/improve) - baseline, single change, named owner, re-measure plan.
- Week 4: confirm the change has run, re-measure on the same scope, and record released time (or a null result, which is equally valid).
The deliverable at day 30 is one completed experiment card with a measured before/after and an owner - not a dashboard tour. That single verified loop is what proves adoption and what the next process copies.
Interpretation check
Adoption is measured by reviewed findings and measured time released, not by how many findings the product generated. A discovered workflow is inferred and confirmed with the customer; friction and rework are hypotheses, not proven waste; conformance depends on the chosen reference path - so the review-and-validate loop, not the finding count, is the thing being adopted.
In the field
KnackGlobal RCM: adoption is not 'friction findings on the claim process' - it is one validated experiment on a waiting step that moves days-in-AR, with an owner and a measured before/after. That single verified loop, repeated, is what outlasts the ProHance comparison and the consultant's one-off process map.
Practical task
For one real assigned account, write the 30-day adoption plan: the one process and owner you would pilot on, how you would confirm detection confidence and taxonomy, the single finding you would validate, the experiment card (baseline, change, owner, re-measure), and the weekly/monthly/QBR cadence. State the one adoption risk most likely to bite this account and your counter.
Self-check
A customer says 'we're fully adopted, we have 300 friction findings'. Why is that not adoption?
A large finding count is a backlog, not adoption. Findings are inferred hypotheses with a confidence. Adoption is the running loop of reviewed, de-duplicated findings turned into validated before/after experiments with owners and measured released time. 300 unreviewed findings and zero experiments means the loop is not running.
What is the single milestone that ends the pilot stage?
Detection confidence and taxonomy confirmed on one process, with one validated finding turned into one tracked experiment that has a named owner - not 'friction found'.
Why cap the number of live improvement experiments?
To stop the finding backlog. The scarce resource is human review and owner attention, not generated findings. Promoting few and finishing them produces measured released time; promoting many produces an unreviewed queue.
Which metric is the honest outcome to report at a QBR, and which must stay out of the headline?
Report measured time released against the customer's own baseline. Keep the modelled opportunity estimate out of the headline - it is a hypothesis, not a result, and presenting it as the saving is the exact error the app's discipline exists to prevent.
A works council raises a privacy concern mid-rollout. Where does this belong in the plan?
Early, as a named adoption risk. Use the privacy and evidence screen to show aggregation and traceability, confirm real capture and access with the customer's security owner, and never overclaim capture from the demo. Resolving it is a precondition for scale, not an afterthought.
Verified vs demo. The staged screens (detection, discovery, friction, step time, improvement workspace, taxonomy, privacy) are demo-shown on seeded data. The actual detection method, confidence, coverage, available metrics and privacy configuration for a customer must be confirmed with product and anchored to the customer's own baseline.