The Short Answer
A login proves someone entered the system. It doesn’t prove work was done within it, that entered data is reliable, or that a manager can make decisions based on it. An organization reporting 92% logins while simultaneously managing forecasts in Excel hasn’t adopted Salesforce; they’ve merely opened it.
A useful adoption metric answers one question: Is the business process running end-to-end within the system, at a quality level that allows reliance on it? From this, four layers of measurement are derived: core actions, data quality, process speed, and business outcome.
Three Levels of Adoption
| Level | What’s Measured | Example | What It Means |
|---|---|---|---|
| Presence | Login, time spent | 92% logged in this week | Almost nothing |
| Active Use | Core actions by role | 78% of opportunities updated within 7 days | The process is running |
| Value | Business outcome + quality | Forecast variance dropped from 31% to 12% | Adoption paid off |
Most organizations get stuck at the first level because it's the only one available without effort. The next two levels require a preemptive decision: what constitutes a "core action" for each role.
How to Define a Core Action
A core action is the action without which the process breaks. Not the most common action—the most critical one. For a sales rep, this is typically updating stage and close date; for a sales manager, it's a weekly Pipeline review within Salesforce; for a service agent, it's closing a Case with the correct reason code.
The practical rule: If the action isn't performed, someone downstream is working with incorrect information. If no one is negatively impacted by its absence, it's not a core action, and sometimes shouldn't even be a required field.
For each role, define one to two core actions, explicitly document them in the job description, and measure the percentage of users who performed them within the relevant process timeframe.
Data Quality Layer
A poorly executed action is sometimes worse than an unexecuted one, as it generates false confidence. Therefore, every quantitative metric needs a qualitative counterpart:
- Percentage of opportunities with a past close date - Pipeline decay metric.
- Percentage of Cases closed with a generic "Other" reason code - Broken categorization metric.
- Percentage of customers without an active contact person - Missing foundational data metric.
- Percentage of manually created duplicate records - Entry process failure metric.
These four metrics will reveal within a week whether the system is in real or merely ceremonial use. Further details on root cause resolution are available in Improving Salesforce User Adoption.
Segmentation: The Average Lies
An organizational average of 70% adoption can hide one team at 95% and another at 20%. All measurements must be segmented by at least three criteria:
- Role – Agent, Manager, Back Office. Each has different expectations.
- Team or Direct Manager – The biggest difference in adoption is almost always the direct manager, not the training.
- Tenure in the system – Users who joined after the Go Live did not receive the same training, and their data indicates the onboarding process.
When the gap between the leading team and the lagging team is greater than two-fold, the problem is managerial, not systemic, and the correct investment is in the management layer, not in further development.
Baseline: The Error You Can't Fix After the Fact
A metric without a reference point is a meaningless number. The Baseline is measured before the change – even if manually measured, even if estimated. Ask: How long does it currently take to close a Case? How many opportunities are updated on time? What was the forecast variance for the last three quarters?
If the Baseline isn't measured before launch, it can partially be reconstructed from historical data, but behavioral metrics cannot be recovered. This is why adoption measurement is a planning phase decision, not a Go Live phase decision.
From Finding to Action
The following table maps common findings to the correct action. The rationale: almost no adoption finding is resolved by additional training.
| Finding | Probable Root Cause | Recommended Action |
|---|---|---|
| High logins, low core actions | System is not part of the daily workflow | Integrate into process: alerts, Path, work lists |
| Actions performed but weeks late | No management cycle relies on the data | Weekly Pipeline review from a Dashboard |
| Low quality in a specific field | Field is irrelevant or unclear | Reduce, change to Picklist, or remove |
| A single team is lagging | Direct manager is not a user | Work with the manager, not the team |
| All fields filled but management doesn't trust | Mismatch between metric and business question | Redefine the outcome metric |
What It Looks Like in a Monthly Report
A good adoption report fits on one page: four metrics with a three-month trend, segmentation by team, three findings, and three actions with an Owner and date. Without actions, it's a status report; with actions, it’s a management tool.
The link between measurement and organizational work plan is detailed in Salesforce Change Management Plan, and the training planning derived from findings is found in Salesforce Role-Based Training.
Summary
Adoption metrics are not a report card for users; they are a fault detection system for the process. If measurement does not lead to changes in the process, interface, or management layer, it only creates work. Start with four metrics, segment by team, establish a Baseline, and link each finding to an action with an owner.