You paid for the system — your team is still doing it the old way: the software adoption gap
Software returns nothing until people use it. The failure is almost never the software — it is adoption, and it is the most under-budgeted line in any systems project. The return lives in the rollout, not the purchase order.
You signed off on the new system. The licences are paid, the thing is deployed, the logins work, and there was a kickoff meeting with slides. Three months later the sales team still runs on WhatsApp and a shared spreadsheet, the new CRM has a handful of stale records in it, and the dashboard you were promised shows mostly blank. Nobody broke anything. The software works exactly as sold. It is just empty — because the people it was bought for never actually moved onto it.
This is the adoption gap, and it is the quietest way a systems project fails. The purchase was treated as the finish line, when it was barely the starting one. Software produces nothing on its own; its value is a function of how much of the real work flows through it. An unused system is not a half-win you can fix later — it is a full loss plus a recurring bill, and the old manual way still grinding along underneath. The failure mode here is not technical. It is human, and it is almost entirely predictable.
This piece separates two sentences that sound identical and mean opposite things: "we have a system" and "we run on the system." It puts real numbers on how wide the gap usually is, names the four reasons the new system loses to the old habit, and lays out the build-and-rollout decisions that close it. Because the difference between a tool that pays for itself and one that sits on the shelf is rarely the tool — it is whether anyone designed for the day after launch.
Start with the failure rate, because it is much higher than the brochure implies and it has barely moved in a decade. Forrester puts the share of CRM projects that fall short of expectations at around 49 percent [1]; a widely-cited Merkle study found 63 percent of CRM initiatives failing, and the number has not improved in the years since [2]. Dig into why and you stop finding broken software. The single largest cause, across study after study, is poor user adoption — roughly half of failed implementations trace back to it [3]. The tool was fine. The people never came.
This is not a CRM quirk; it is the general shape of every system rollout. McKinsey has long held that around 70 percent of large-scale change and transformation efforts fall short of their goals, and the reason is almost never that the technology did not work — it is that people do not change how they behave [4]. A new system is a behaviour change wearing a software costume. You are not really asking your team to install an app; you are asking them to abandon a habit they are fast and comfortable at, and to be slower and clumsier for a while in exchange for a benefit that mostly accrues to the business, not to them in the moment. Stated that way, the resistance is not laziness. It is rational.
And "adopted" is not a yes-or-no light. Even among teams that do log in, roughly 43 percent use fewer than half the features of the system they are paying for [5], and in six out of ten companies more than a tenth of the people who are supposed to be on it effectively are not [6]. Shallow adoption is its own tax: you pay the full sticker price for a fraction of the capability, and — worse — every report and forecast the system produces is now built on partial data. This is exactly where the systems chain breaks. The reporting you bought the tool for is only as honest as the share of reality that actually got entered.
The reasons the new system loses are boringly consistent, and naming them is half the fix. First, friction: manual data entry feels like time stolen from the real job, so reps skip it. Second, no migration: the old spreadsheet still holds the live data, so people stay where the data is. Third, the parallel path: the old way still works, which quietly makes the new way optional — and optional loses. Fourth, training as a one-time event: a single demo at launch, then nothing, against a forgetting curve that erases most of it within weeks. In every case the new system is competing head-to-head with an entrenched habit, and unless someone tilts the field, the habit wins by default.
So the fix is not a sterner email or a longer training day — it is a build-and-rollout decision made before launch. Design the system around the workflow people already have, not the one the vendor assumed. Migrate the data fully, so the old place is empty and there is nothing to go back to. Remove the parallel path: make the new system the only way to get paid, booked, or reported, so using it is the path of least resistance rather than the virtuous extra step. Cut entry friction with capture-at-source, autofill, and a phone-shaped interface. And treat usage as a first-class metric you watch weekly, the same as revenue. This is where owning your system instead of renting a generic one pays off twice: you can bend the software to fit how your team actually works, instead of bending your team to fit a screen designed for someone else's.
The software is fine and the rollout was clear — the gap is discipline. Mandate it, run more training, tie it to performance reviews, and the adoption will follow. People resist any change; management's job is to hold the line until the new way becomes routine. Spend on enforcement and accountability, not on re-engineering a tool that already does the job.
You cannot train your way out of a bad interface. If half the team will not touch it, the system is too heavy, too ugly, or too slow for the way they actually work. Rip it out and replace it with something simpler — or let an AI layer do the data entry no human wants to do. Fix the experience and adoption takes care of itself; fighting your people is treating the symptom.
Adoption is not a personality trait or a UI accident — it is something you build for. Fit the system to the real workflow, migrate the data so the old place is dead, kill the parallel path so the new way is the only way, capture data at the source, and measure usage as a metric that matters. Get the structure right and you need far less enforcement and far less rescue-by-redesign.
Camp C, with the other two as supporting players. Training (Camp A) and a humane interface (Camp B) matter at the margins — but on their own they are rescue work after a rollout that was never designed. The durable fix is structural: build the system around how the work actually flows, remove the path back to the old way, and make the right way the easy way. Do that and adoption stops being a willpower contest. Skip it and no amount of training or tool-swapping will save the spend.
- 01For the systems you already pay for, what share of the people who are supposed to use them actually run their daily work through them — and have you ever measured it, or only assumed it?
- 02When you bought your last system, how much of the budget went to the rollout — migration, workflow design, training, usage tracking — versus the licences and the build? And which half decided whether it worked?
- 03Is there still a parallel path — a spreadsheet, a chat thread, a paper form — that lets your team get the job done without touching the new system? If so, which one are they actually using?
- 04How much of the reporting you rely on is built on partial data because adoption is shallow — and would you make the same decisions if you knew what fraction of reality is missing from it?
- 05When adoption stalls, how do you tell whether the real problem is discipline, the interface, or a rollout that never removed the old habit — and does your fix match the actual cause or just the easiest one to blame?
- [1]Forrester — "CRM Success Requires Focus On People, Not Only Technology": roughly 49% of CRM projects fall short of expectations, and adoption is a people problem before it is a technology one.
- [2]DMNews — "63% of CRM initiatives fail" (Merkle Group study): CRM failure rates have not improved in a decade, with user adoption the leading cause.
- [3]Radin Dynamics — "The CRM Implementation Crisis: 50% Fail Due to Poor User Adoption": about half of failed CRM implementations trace directly to users not adopting the system.
- [4]McKinsey & Company — "Why do most transformations fail? A conversation with Harry Robinson": around 70% of large-scale change efforts fall short, almost always because people do not change their behaviour, not because the technology failed.
- [5]DesignRush — "CRM Statistics: Usage Trends, Business Impact & ROI Insights": about 43% of CRM users use fewer than half of the available features, often because they find them too complex.
- [6]FullEnrich — "CRM Adoption Rates: Insights, Challenges, and Strategy for Businesses": only 40% of businesses claim a 90% adoption rate, and in six out of ten companies more than 10% of the people who should use the CRM do not.
We build the system and the rollout — so a login becomes a habit, not a line item.
A system that fits the workflow, a clean migration that empties the old spreadsheet, the parallel path removed, and usage measured from day one. Owning it means we bend the software to your team, not the other way round. Fifteen minutes to map where your adoption is leaking and what it would take to close it.
Book a free 15-min consultation