Adoption
Part of Expansion readiness
Checking adoption before suggesting an upgrade
Check existing entitlements, meaningful use and customer outcomes before recommending an upgrade.
Before suggesting an upgrade, establish whether the customer is using what it already has to complete the intended task. Check the relevant users, workflow and time period, then ask the customer what the activity means. The result may support an upgrade, reveal an adoption barrier or show that the current arrangement is sufficient.
Start with the entitlement and the task
Confirm what the customer has bought, who can access it and which workflow the proposed upgrade is meant to improve. An assigned licence is different from actual use. A login is different from completing a useful task. Choose a measure that reflects the work, such as whether the appropriate role completes the process when it is due.
Use a period that fits the customer's operating cycle. A monthly approval task can look dormant in a weekly view. Check whether tracking gaps, account mapping or role changes could explain a surprising pattern. Product data is a prompt for a conversation, not a complete account of the customer's results.
Key Adoption Metrics to Review
- Licence Assigned
- Yes (verified via product access logs)
- Active Users in Key Workflow
- 3 out of 5 assigned roles
Read the pattern before acting
| Adoption finding | Question to resolve | Next action |
|---|---|---|
| Core workflow is used and demand is reaching a relevant limit | Who needs additional access or capability, and for which task? | Evaluate the smallest relevant change |
| An existing purchased feature is little used | Is the obstacle awareness, setup, fit or priority? | Address the obstacle and reassess |
| Activity is high but the outcome is unclear | Is the work helping the customer? | Agree an outcome measure before proposing more |
| Use is low for a periodic task | Is that frequency expected? | Compare use with the actual task cycle |
These rows are prompts, not automatic rules. A customer can have a new use case while adoption elsewhere is low. Heavy use of one feature does not prove that a higher tier is needed.
Ask about the gap behind the data
Show the customer the specific observation and invite correction. Ask: “We see this workflow used by one team; is another team now expected to use it?” Ask whether people work outside the product, wait for access, cannot complete a step or have simply finished the task. Check open service issues before assuming non-use is a training problem.
If the existing product can meet the need, agree an adoption action, owner and review point. If a confirmed limit prevents an outcome, define what an upgrade would change and what the customer would need to do to gain that benefit. Where evidence remains mixed, offer a scoped evaluation instead of a broad promise.
Record the current entitlement, meaningful use, customer explanation, unresolved barrier and next decision. This makes the recommendation reviewable and reduces the risk of asking the customer to buy around an undiagnosed problem.
