Diagnose adoption gaps
Objective. Distinguish the five layers of adoption - entitlement, configuration, usage, repeated routine and realised outcome - so you can locate exactly where a capability has stalled and apply the right intervention rather than a generic 'drive usage' push.
'Adoption is low' is not a diagnosis. This lesson gives you a five-layer model that pinpoints whether the problem is that the customer is not entitled, not configured, not using, not using in a routine, or using but not getting the outcome - because each layer needs a completely different fix. A capability adoption assessment built this way turns a vague worry into a targeted, follow-up-able plan.
See it in the demo
The customer problem
A sponsor says 'we are not getting value' and the untrained CSM reaches for the generic lever - more training, more nudges to log in. Often that is the wrong fix entirely. The capability may not be entitled, so no amount of nudging will help. It may be entitled but misconfigured, so usage produces garbage. It may be used but only sporadically, never as a routine, so it changes no decisions. Or it may be fully used in a routine and still not moving the outcome, which points to the success-plan assumption, not adoption at all. Business impact: misdiagnosed adoption wastes the customer's goodwill on the wrong intervention and leaves the real blocker untouched, so the account stalls while everyone feels busy.
How Time Champ addresses it - the five layers
Diagnose each capability against five layers, in order, because a lower layer failing makes the ones above meaningless. (1) Entitlement: is the capability actually part of what the customer bought and licensed - confirm with product, do not assume. (2) Configuration: is it set up correctly - coverage, mappings, standards, access (the C02 checklist)? (3) Usage: is anyone actually opening and using it - evidence of activity, not just a login. (4) Repeated routine: is the usage a sustained cadence with owned actions (C06), or a one-off look? (5) Realised outcome: is the customer's success-plan measure actually moving (C01, C08)? Walk the layers with evidence from the apps - Employee Monitoring for coverage/usage signals, the relevant application's own activity and the action log for routine, the success measure for outcome. The layer where the chain first breaks is the one to fix; fixing a higher layer while a lower one is broken wastes effort.
What to say / do - capability adoption assessment
Produce a short assessment per key capability: a row per capability with a pass/fail/unknown at each of the five layers, the layer where it first breaks, the intervention matched to that layer, an owner and a follow-up date. Match the intervention to the layer: entitlement gap -> commercial conversation, not training (this may be an expansion, see C09); configuration gap -> validation and possibly a specialist escalation (C02); usage gap -> enablement and removing a practical blocker; routine gap -> build the cadence and action log (C06); outcome gap with everything else healthy -> revisit the success hypothesis and confounders (C08), because the problem is the theory of value, not adoption. Talk track to the sponsor: 'Usage is actually fine - the gap is that it is not yet a routine with owned actions, so let us fix that rather than retraining people who already know the screens.'
Reading usage without over-reading it
Be careful interpreting usage signals the way you would teach a customer to be careful (C05). A login is not usage; opening a screen is not a routine; a routine is not an outcome. Equally, low usage of one capability is not failure if the customer's success plan never depended on it - do not manufacture an adoption problem for a feature nobody needed. Carry the honesty guards: a non-productive application label is not proof of no work, so do not read activity data as a morality verdict; recovered capacity is not cash, so 'they adopted Value Leakage' is not the same as 'they realised financial value'. The assessment is about whether the capabilities that serve the agreed outcome are healthy, not about maximising logins across every module.
Objections and honest limits
'Just run more training' - only if the diagnosis says the gap is usage or routine; training an entitlement or configuration gap wastes everyone's time. 'Our usage numbers look great' - usage without routine or outcome is a comfortable illusion; probe the upper layers. 'The outcome is not moving, so the product failed' - if entitlement, config, usage and routine all pass, the issue is likely the success hypothesis or a confounder, which is a planning conversation, not a product failure. Honest limits: whether a capability is entitled is a product/commercial fact to confirm, not assume; where you cannot see usage evidence directly, say so rather than guessing. Do not label an account 'low adoption' without naming the specific layer and capability - an unspecific label triggers the wrong fix.
Interpretation check
'Low adoption' is never the diagnosis - it is the symptom. Name the specific capability and the exact layer (entitlement, configuration, usage, routine or outcome) where the chain first breaks, because each layer demands a different intervention.
In the field
At KnackGlobal, if output-per-FTE is not moving despite heavy Work Output usage, the diagnosis is usually an outcome-layer issue - a confounder like volume mix or a standard not yet trusted - not low adoption; pushing more training would miss the real blocker in the ProHance displacement case.
Practical task
For your account, build a capability adoption assessment: a row for each key capability with pass/fail/unknown across the five layers, the first-broken layer, the matched intervention, an owner and a follow-up date. Include at least one capability whose first-broken layer is NOT usage (e.g. a routine gap or an outcome gap) and justify the non-training intervention.
Self-check
Name the five layers in order and why order matters.
Entitlement, configuration, usage, repeated routine, realised outcome. Order matters because a broken lower layer makes the higher ones meaningless - usage on a misconfigured capability produces garbage, so you fix the lowest broken layer first.
A capability shows strong usage but the outcome is flat. Where is the likely problem and what is the intervention?
If configuration, usage and routine all pass, the problem is usually the realised-outcome layer - the success hypothesis or a confounder - not adoption. The intervention is a success-plan/QBR conversation (C01, C08), not more training.
Why is 'run more training' the wrong move for an entitlement or configuration gap?
Training teaches people to use something that either is not licensed (entitlement) or is set up to produce wrong data (configuration). No amount of training fixes those layers - they need a commercial conversation or validation/escalation respectively.
A customer barely uses one module and the CSM wants to push it. When is that a mistake?
When that module was never part of the agreed success plan. Manufacturing an adoption problem for a feature the outcome never depended on wastes goodwill. Adoption is measured against the capabilities that serve the agreed outcome.
Verified vs demo. Usage and outcome signals are demo-shown in the apps. Entitlement is a commercial/product fact that must be confirmed, not inferred from the demo; where usage evidence is not directly visible, state it as unknown rather than assumed.