CRM Adoption Measurement: Metrics Beyond the Login Count

Abstract

Most organisations that claim to measure CRM adoption measure logins, and logins measure presence rather than adoption. The distinction is not rhetorical. Three decades of research on sales technology and information-systems success converge on the finding that what predicts value is not whether users open the system but how the system participates in their work — the quality and depth of use, not its frequency (DeLone and McLean 2003; Burton-Jones and Straub 2006). The same literature documents how adoption fails: favourable first impressions decaying into rejection within months, intention diverging from behaviour over time, and identical deployments producing opposite outcomes depending on training and support (Speier and Venkatesh 2002; Jones, Sundaram, and Chin 2002; Ahearne, Jelinek, and Rapp 2005). This reference converts those findings into a measurement model with three layers — presence, behaviour, reliance — and instruments each layer with reports HubSpot supports natively, using property completeness, activity currency and forecast provenance as its three primary metrics. It closes with the gaming problem every behavioural metric creates, and with the limits of measuring adoption at all.

1. Definitions

Adoption — in this reference, the state in which a system is the medium of the work it was bought for, not merely available to that work. Adoption is a property of an organisation, not of an individual.

Acceptance — an individual's disposition to use a system, the construct the technology-acceptance literature models (Davis 1989). Acceptance precedes use and does not guarantee it.

Infusion — the degree to which a technology is embedded in the tasks it supports, as distinct from operated alongside them (Hunter and Perreault 2007).

Presence metric — a measure that a user showed up: logins, seat activations, sessions.

Behaviour metric — a measure that the work passed through the system: records created and updated, activities logged, fields populated at the moment the process required them.

Reliance metric — a measure that decisions consumed the system's output: forecasts assembled from pipeline data, meetings run from dashboards, coaching anchored to logged activity.

2. What the Research Establishes

Adoption is commonly treated as a deployment milestone: the system goes live, the team is trained, and the project closes. Three separate bodies of research contradict that view. Each asks a different question, and read together they explain why adoption decays and what is worth counting.

Research on technology acceptance asks what makes an individual willing to use a system at all. Davis (1989) tested two candidate predictors — how useful a person believes a system to be, and how easy they believe it is to operate — and found the first dominated the second. Users forgive friction in a tool that visibly helps them, and do not forgive elegance in one that does not. Venkatesh and colleagues (2003) later consolidated eight competing acceptance models into a single framework, the Unified Theory of Acceptance and Use of Technology. Two of its factors matter here. Social influence is the pressure a user feels from colleagues and managers. Facilitating conditions are the training, help and management backing actually available to them, and in the pooled data these predicted use directly rather than working through intention. Support is therefore a determinant of adoption, not a courtesy extended around it.

Research on sales-force automation asks what happens to those dispositions over time, and its findings are hard to reconcile with a milestone view. Speier and Venkatesh (2002) followed salespeople through two separate automation deployments, measuring attitudes immediately after training and again six months later. Initial reactions were favourable in both. Within six months both systems had been widely rejected, and the researchers recorded declines in job satisfaction and organisational commitment alongside the rejection. Jones, Sundaram, and Chin (2002) found the same shape over time: intention to use the system predicted early use, and use decayed afterwards, so a figure taken at week four flatters what exists at month eight. Ahearne, Jelinek, and Rapp (2005) supply the qualifier that governs how any of this should be measured. In their field data, automation improved salesperson performance where training and support were present and failed to improve it where they were absent. The same adoption number therefore means opposite things in two firms, and cannot be interpreted without knowing which. Morgan and Inks (2001) found acceptance rising with user involvement in the rollout, with training, and with perceived management support — three conditions a firm chooses rather than inherits.

Research on information-systems success asks what to count. DeLone and McLean (2003) revisited their own success model after a decade of studies applying it, and placed use and user satisfaction as linked mediators between the quality of a system and the benefits it eventually produces. Their argument about use is the part that matters here: use should be understood as a question of quality and appropriateness, not of frequency. Burton-Jones and Straub (2006) made that operational. They redefined usage as a relation between three things — a user, a system, and the task being performed — and showed empirically that measures capturing all three predicted performance while thinner measures did not. A login count captures the user and the system and omits the task, which is the part that produces revenue.

3. A Three-Layer Measurement Model

The model that follows converts the research into instrumentation. Each layer answers a different question, and the layers are ordered: a failure at a lower layer makes the layers above it meaningless.

Presence answers whether users can and do show up: seats activated, logins per user per week, mobile app usage where field work matters. Presence is necessary and nearly worthless alone — it is the layer most vulnerable to compliance behaviour, since a login can be performed without any work passing through the system. Its proper role is as a tripwire: a user whose presence drops to zero has abandoned the system, and the research on decay suggests looking for this from the second month, not the second year (Jones, Sundaram, and Chin 2002).

Behaviour answers whether the work passes through the system, and it is where measurement should concentrate. The operational questions are concrete. Are records created where the process says they should exist — a deal for every qualified opportunity, a ticket for every service request? Are they current — what share of open deals has had no logged activity in thirty days, what share carries no future-dated task? Are they complete at the moments completeness matters — what share of deals reaches each stage with the stage's required properties populated? Behaviour metrics are leading indicators in the strict sense: they tend to move weeks before pipeline accuracy and forecast reliability move, because they measure the inputs those outcomes are computed from.

Reliance answers whether the organisation consumes what the system produces, and it is the layer the literature identifies with realised value (DeLone and McLean 2003). Its signals are organisational rather than individual: the forecast presented to leadership is generated from pipeline data rather than assembled in a spreadsheet; pipeline reviews run from live views rather than prepared decks; coaching conversations reference logged activity. Reliance is harder to instrument than behaviour and worth the trouble, because it is self-reinforcing — a rep whose forecast is read from the CRM keeps the CRM accurate in self-defence, which is the only enforcement mechanism that scales (Hunter and Perreault 2007).

4. Instrumenting the Layers in HubSpot

The model's virtue is that HubSpot can instrument most of it without additional software, using surfaces the platform already documents.

Behavioural completeness is measured from properties. Every object carries default properties suited to currency measurement — last activity date, last modified date, create date, close date among them — and the custom report builder can count records by owner where a required property is unknown, which turns "property completeness at stage" into an ordinary saved report: open deals by owner, filtered to a stage, split by whether the amount, close date or next-step field is populated. The same pattern measures currency — open deals with a last-activity date older than thirty days, by owner — and staleness at the record level, contacts with no activity since creation. Where the process demands completeness at a boundary rather than in aggregate, stage-level required properties, configured per pipeline in deal settings, move the measurement from report to enforcement; the trade-off is friction, and the acceptance literature counsels spending friction only where usefulness is already visible (Davis 1989).

Two instrumentation habits raise the signal quality considerably. First, measure by role and cohort rather than by portal average, because the research's decay curves are individual — a healthy mean reliably conceals three abandoners and two heroes (Jones, Sundaram, and Chin 2002). Second, date-stamp the baseline: adoption metrics are only interpretable against the deployment's own history, and a property's completeness rate at month zero is the denominator every later reading needs. The reporting layer itself needs almost no construction; what needs construction is the habit of reading it on a schedule, which section 6 returns to.

Reliance is instrumented partly in the platform — dashboard views, forecast submissions where the forecasting tool is in use — and partly by observation: whether the Monday meeting opens the dashboard or a spreadsheet is a data point no API exposes, and a truthful adoption review collects it anyway.

Two hazards are worth drawing, because both produce an adoption figure that is wrong in the flattering direction. The first is coverage: a report describes the records it can see, and a portal whose deals arrive by import or integration can show a healthy completeness rate computed over a fraction of the business.

The second is arithmetic. A report joining objects returns a row per association, so a measure summed across a join counts a record once per associated contact rather than once — and an adoption metric built that way improves whenever anybody adds an association.

5. Targets and the Gaming Problem

A behavioural metric published with a target attached induces the behaviour that satisfies the metric, which is not always the behaviour the metric was built to represent. Activity logging measured on its own produces logged activity rather than selling: calls of no duration, notes with no content.

Campbell (1979) stated the general case while reviewing social programmes evaluated on quantitative indicators. The more any indicator is used to make decisions, the more it comes under pressure to be corrupted, and the more it distorts the process it was meant to monitor. Goodhart observed the same thing in monetary policy: a statistical regularity tends to break down once it is targeted. Neither claim concerns the honesty of the people being measured. Both describe what predictably happens to a number once decisions depend on it, which is why the response is a design change rather than an appeal to conduct.

The design response is to publish behavioural metrics in pairs that are expensive to satisfy dishonestly at the same time: activity volume alongside deal progression, property completeness alongside forecast accuracy, record currency alongside win rate by owner. One metric of a pair can be inflated cheaply. Inflating both usually requires doing the work.

The second discipline is to treat metric deterioration as information rather than infraction. The SFA literature's most practical finding is that use collapses where the tool's usefulness is not experienced, and that training and support moderate everything downstream (Ahearne, Jelinek, and Rapp 2005; Venkatesh et al. 2003). A team whose behaviour metrics sag in month three is often reporting, at least in part, a defect in the deployment — a slow view, a redundant field, a report nobody shows them — rather than a defect in character, and an adoption programme that answers sagging metrics with mandates rather than diagnosis is measuring its way toward the rejection curve Speier and Venkatesh (2002) documented.

6. The Review Cadence

Measurement without a standing consumer decays into ritual. The cadence that works in practice is unglamorous: a monthly review, attended by sales leadership and whoever owns the platform, that reads the three layers in order — abandonment tripwires first, behavioural cohorts second, reliance signals third — and leaves each meeting with at most a few interventions, each aimed at a diagnosed cause rather than a low number. The implementation literature has said for twenty years that sustained executive attention distinguishes systems that stay adopted from systems that were merely launched (Umble, Haft, and Umble 2003); the review cadence is what sustained attention looks like at the scale of a CRM.

The interventions themselves come from the moderator research rather than from the metrics: targeted retraining where a cohort's breadth of use is narrow, support and configuration work where friction is reported, involvement — asking the resisting team to redesign the offending view — where the resistance is positional, and management modelling where reliance is the weak layer, since reps conclude what matters from what their managers open in meetings (Morgan and Inks 2001; Ahearne, Jelinek, and Rapp 2005).

7. Limits

The model has four boundaries. Behavioural metrics measure what passes through the system, and some high-value selling behaviour never does; a measurement regime that forgets this taxes exactly the work it cannot see. The reliance layer resists full instrumentation, and the observational part of it is subjective in ways the numbers beneath it are not. The research base is strongest for sales-force automation in B2B field sales between the mid-1990s and late 2000s; its transfer to modern multi-hub CRM platforms is an argued analogy and may hold imperfectly, and the platform-specific instrumentation in section 4 reflects HubSpot's documented behaviour as of August 2026, which changes on the vendor's schedule. Finally, adoption measurement answers whether the system is used, not whether the system was worth buying — net-benefit questions need revenue and efficiency evidence that this reference's metrics feed but do not settle (DeLone and McLean 2003).

8. Conclusion

The login count survives as an adoption metric because it is easy, not because anyone defends it. The research offers a better and still practical position: measure presence as a tripwire, behaviour as the leading indicator, and reliance as the outcome, pair every published metric with its expensive-to-fake complement, and read the results as diagnosis rather than verdict. None of this requires software beyond what a HubSpot portal already contains. It requires deciding that adoption is an ongoing organisational behaviour rather than a launch milestone — which is, on the evidence of three decades of system deployments, simply what adoption is.

References

Ahearne, Michael, Ronald Jelinek, and Adam Rapp. 2005. "Moving Beyond the Direct Effect of SFA Adoption on Salesperson Performance: Training and Support as Key Moderating Factors." Industrial Marketing Management 34 (4): 379–388. https://doi.org/10.1016/j.indmarman.2004.09.020

Burton-Jones, Andrew, and Detmar W. Straub Jr. 2006. "Reconceptualizing System Usage: An Approach and Empirical Test." Information Systems Research 17 (3): 228–246. https://doi.org/10.1287/isre.1060.0096

Campbell, Donald T. 1979. "Assessing the Impact of Planned Social Change." Evaluation and Program Planning 2 (1): 67–90. https://doi.org/10.1016/0149-7189(79)90048-X

Davis, Fred D. 1989. "Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology." MIS Quarterly 13 (3): 319–340. https://doi.org/10.2307/249008

DeLone, William H., and Ephraim R. McLean. 2003. "The DeLone and McLean Model of Information Systems Success: A Ten-Year Update." Journal of Management Information Systems 19 (4): 9–30. https://doi.org/10.1080/07421222.2003.11045748

Hunter, Gary K., and William D. Perreault Jr. 2007. "Making Sales Technology Effective." Journal of Marketing 71 (1): 16–34. https://doi.org/10.1509/jmkg.71.1.016

Jones, Eli, Suresh Sundaram, and Wynne Chin. 2002. "Factors Leading to Sales Force Automation Use: A Longitudinal Analysis." Journal of Personal Selling & Sales Management 22 (3): 145–156. https://doi.org/10.1080/08853134.2002.10754303

Morgan, Amy J., and Scott A. Inks. 2001. "Technology and the Sales Force: Increasing Acceptance of Sales Force Automation." Industrial Marketing Management 30 (5): 463–472. https://doi.org/10.1016/S0019-8501(99)00115-7

Speier, Cheri, and Viswanath Venkatesh. 2002. "The Hidden Minefields in the Adoption of Sales Force Automation Technologies." Journal of Marketing 66 (3): 98–111. https://doi.org/10.1509/jmkg.66.3.98.18510

Umble, Elisabeth J., Ronald R. Haft, and M. Michael Umble. 2003. "Enterprise Resource Planning: Implementation Procedures and Critical Success Factors." European Journal of Operational Research 146 (2): 241–257. https://doi.org/10.1016/S0377-2217(02)00547-7

Venkatesh, Viswanath, Michael G. Morris, Gordon B. Davis, and Fred D. Davis. 2003. "User Acceptance of Information Technology: Toward a Unified View." MIS Quarterly 27 (3): 425–478. https://doi.org/10.2307/30036540