Software Adoption: Why Training Solves the Wrong Problem

Imagine you send everyone to a cooking class before opening a restaurant. The chefs learn the recipes, taste the dishes, practice the techniques. Then they return to the kitchen, where the knives are in different drawers from where they were taught, the stove runs hotter than the practice one, the tickets come in faster than any simulation prepared them for, and the habit of reaching for the familiar shortcut is stronger than three hours of instruction.

That is software adoption, exactly. The training event is the cooking class. The software is the restaurant kitchen. The gap between the two is why Gartner found that 55% of enterprise software implementations fail to reach their intended business outcomes, and why most post-mortems identify “user adoption” as the cause while almost never examining whether the adoption program was built on a theory that could work (Gartner, “Why ERP Implementations Fail,” 2023).

Software adoption is the degree to which people use a tool the way it was meant to be used, sustained over time, and it is a behavioral outcome, not a training outcome, which is why adoption programs built around kickoffs and courses reliably fail to produce the behavior change the software was purchased to create.

Why does software adoption so reliably fail after training?

Hermann Ebbinghaus ran a precise and uncomfortable experiment on himself in 1885. Over months of memorization trials, he charted exactly how quickly learned material decayed without reinforcement. The forgetting curve that resulted showed that people forget roughly 50% of new information within 24 hours, approximately 75% within a week, and close to 90% within a month (Ebbinghaus, Memory: A Contribution to Experimental Psychology, 1885). He was measuring syllables, not software workflows, but every transfer-of-training study since has found the same shape. Training produces knowledge. Without reinforcement in context, the knowledge decays.

The training industry has known this since at least the 1980s, when learning researchers Mary Broad and John Newstrom surveyed the literature and found that only 10% of what was taught in a corporate training environment transferred to on-the-job behavior, and most of what transferred had evaporated within six months (Broad & Newstrom, Transfer of Training, 1992). The 90% that did not transfer was not forgotten because the people were undisciplined or uninterested. It was not transferred because the conditions at work did not support it: the habit cues pointed elsewhere, the friction of the new behavior was higher than the friction of the old one, and no prompt appeared at the moment it was needed.

This is the core of the software adoption challenges organizations face. A user who completes a 45-minute CRM training session and returns to their desk knows, in that moment, how to log discovery notes correctly. When the next sales call wraps up three days later and twelve other things are demanding attention, the new behavior competes against the habit of skipping the logging, which has zero friction because it has always been fine before. The training session’s lessons do not survive the competition.

What actually drives software adoption?

B.J. Fogg’s behavior model, developed through his research at Stanford’s Persuasive Technology Lab and published in Tiny Habits (2019), identifies three elements that must converge for a behavior to occur: motivation, ability, and a prompt at the moment of action (Fogg, Tiny Habits, 2019). All three must be present simultaneously. A high-ability, high-motivation person who receives no prompt at the right moment still does not perform the behavior. A person who receives a perfectly timed prompt but lacks the ability cannot act on it.

Most software adoption programs invest heavily in the ability lever (training: the person now knows how) and almost nothing on the prompt lever (is the right next step visible in the moment of work?). They also overestimate how much the motivation lever matters: people who do not use the software are not usually unmotivated. They are facing friction that the motivation of wanting to do their job well is not strong enough to overcome every time.

The friction is structural. A discovery call SOP that lives in a wiki requires the rep to: finish the call, remember that there is an SOP they should consult, navigate to the wiki, search for the right page, read the relevant section, return to the CRM, and complete the required actions, all while the next call is fifteen minutes away. The sequence has too many steps, and any one of them failing means the SOP was not followed. The Fogg model predicts exactly this outcome: the prompt is absent at the critical moment, and the easier behavior (skipping the logging) wins.

The lever that moves software adoption is proximity. How close is the right action to the flow of work? The closer it is, the more reliably it occurs. An inspection prompt that appears inside the CRM, at the exact step where the rep needs it, requires no navigation and no memory cue. A tooltip that reminds the rep what to log after a discovery call, appearing in the deal record they already have open, is closer to the flow of work than any amount of training. Closer wins.

Elton Mayo’s Hawthorne studies at Western Electric in the late 1920s provided another mechanism worth noting. Workers whose behavior was being observed, even in ways that should not have mattered (better lighting, then deliberately worse lighting), consistently outperformed a control group. The awareness of measurement changed behavior (Mayo, The Human Problems of an Industrial Civilization, 1933). Measurement is a lever in its own right. A software adoption program that tracks whether the process was followed, by whom, on which unit of work, and surfaces that information to managers, will get higher adherence than one that only measures logins. The visibility of the measurement is itself part of what produces the behavior.

How should software adoption actually be measured?

Most teams measure software adoption by usage metrics: how many users logged in this week, which features were touched, how many completed the onboarding flow. These are easy to instrument and almost completely uninformative about whether the software is producing its intended outcome.

Usage metrics are odometers. An odometer tells you how many miles the car traveled. It does not tell you whether the car arrived where it needed to go, whether it followed the correct route, or whether the driver is going to need the engine rebuilt next month. A CRM with 87% weekly login rate but poor data quality is a fully “adopted” CRM by the usage-metrics definition. It is also useless for forecasting, coaching, or process measurement.

Behavior metrics ask the question usage metrics skip: is the work the software was purchased to support being done correctly, consistently, on each unit of work? For a CRM, that is: are discovery notes logged on every qualified call? Are deal stages updated to reflect buyer reality, not optimism? Are the required fields populated before deals advance? For a learning management system: are reps completing the required modules before customer calls, or after? For a digital adoption platform: are the guided workflows being used on the specific tasks they were designed for, or bypassed in favor of the old method?

The distinction matters because improving usage metrics does not necessarily improve business outcomes, but improving behavior metrics does. A sales team that logs discovery notes correctly on 90% of deals can be coached at scale, because managers can see what information is missing and when. A team that has 90% login rates but 30% logging rates cannot be coached at scale, because the information is not there.

What does the in-flow model look like for software adoption?

The design implication is straightforward, though it requires changing what a software adoption program is built around. The question is not “how do we train people on this software?” The question is “how do we make the right action in this software the easiest action, at the moment it needs to happen?”

For a sales team adopting a CRM, that might mean: a guided workflow that appears in the deal record after a call is logged, prompting the rep to complete the five required discovery fields before they can advance the stage. Not a training module. A prompt, in the flow of work, at the moment the action is needed, with a completion check built in. The rep does not need to remember the SOP, navigate to a wiki, or recall what they learned in onboarding. The right action is the only action that takes less than one minute.

For a customer success team adopting a health-scoring tool, that might mean: a trigger in the CRM that flags an account when a health score drops, surfaces a three-step playbook for a risk conversation, and requires a completion note before the flag clears. Again, a prompt in the flow of work, not a training event.

This is the territory that digital adoption platforms (DAPs) like those covered in the digital adoption platform guide are designed for: in-app guidance and walkthroughs that appear when and where the user is working. The research on in-flow enablement shows adoption rates two to three times higher than training-only approaches when the guidance is contextual and appears at the right step. The software adoption strategy post covers the three specific levers in detail, including why distance from the work is the strongest one.

The broader principle, covered in digital adoption, is that adoption is a four-rung ladder: access, usage, proficiency, and behavior. Most programs measure the first two rungs and call it done. The rung that matters is the fourth.

What we recommend

Stop building software adoption programs around training events. Training is the third and weakest lever. The Ebbinghaus research on the forgetting curve is over a century old; the transfer-of-training findings have been replicated dozens of times. The question of whether a training session will produce lasting behavior change has been answered, and the answer is: not reliably, not without reinforcement in context.

Build the adoption program around proximity and measurement instead.

• Proximity. Move the right action as close to the flow of work as possible. In-app guidance that appears at the step where the action is needed is stronger than a wiki. A prompt in the CRM is stronger than an email reminder. A required field that surfaces the SOP is stronger than a reference guide.
• Measurement. Track adherence at the level of the unit of work, not at the level of logins. Who followed the process on which deal, and where did it break down? Measurement surfaces drift before it becomes a team-wide regression, and the Hawthorne findings suggest that the visibility of measurement changes behavior before a manager ever acts on it.
• Reinforcement. When a rep drifts from the process, close the loop in the flow of work, not in a quarterly review. A flag in the CRM, a prompt from the manager in the next one-on-one, a coaching moment on the specific step that was missed: these keep the forgetting curve from flattening at 10%.

A software adoption program that does not address proximity and measurement is a training program with a different name. The cooking class is still the cooking class, regardless of what you call it.

The software works. The question is whether the behavior around it has been designed to work too.