Here's a number that should bother you: according to WalkMe, the average enterprise software tool sees only 15-30% of its intended functionality actually used. Not because the tools don't work. Not because the training wasn't delivered. Because nobody designed for adoption in the first place.
I've been sitting in project steering committees for over two decades, and the conversation almost always follows the same arc. Months of careful work on requirements, architecture, security, testing, integrations. Genuine rigour. Then, about three weeks before launch, someone says: "Right, we should probably think about rollout." And the adoption plan - the thing that determines whether any of this investment actually delivers value - gets crammed into a two-page document and handed to someone in operations who wasn't involved in any of the preceding decisions.
It's like building a restaurant with a world-class kitchen, hiring brilliant chefs, sourcing incredible ingredients - and then forgetting to put a door on the front.
We'll run some training sessions after launch and make sure everyone knows how to use it. Adoption is a change management problem, not a design problem.
I hear this constantly. And I understand why it feels true - change management is a real discipline, and training matters. But this framing treats adoption as something you bolt on after the build. A finishing coat. That's exactly why so many digital investments end up as expensive shelfware. Adoption isn't a post-build activity. It's a design requirement, sitting alongside functionality and security in your project governance from day one.
The organisations I've worked with that consistently achieve high adoption rates aren't doing anything exotic. They're just treating adoption as something you engineer into the project, not something you hope for after it.
Honestly, it's not one failure. It's five failures wearing a trenchcoat. Each one is enough to sink adoption on its own. Together, they're devastating.
No structured onboarding sequence. There's an assumption - almost always unstated - that users will figure it out. They won't. I've written separately about client portal adoption rates that hover around 14%, and the pattern is depressingly consistent: the tool launches, a login email goes out, and then silence. No guided first experience. No "here's the one thing to try first." Just a login screen and a prayer. Structured onboarding is the single strongest predictor of sustained usage, and yet it's the first thing cut when timelines get tight.
No user-side value proposition. This one really gets me. The business case was built around what the organisation needs - efficiency gains, cost reduction, data consolidation. But nobody articulated what's in it for the person who actually has to change their behaviour. If your internal comms about the new portal say "this will streamline our operations," you've told the user precisely nothing about why they should care. What does it do for them, specifically, on a Tuesday afternoon when they're already busy?
Complexity that exceeds tolerance. If your new tool requires more cognitive effort than the current workaround, the current workaround wins. Every time. I was working with a professional services firm last year - mid-sized, about 200 people, good culture - that had built a genuinely impressive knowledge management system. But searching for a document took four clicks and a filter selection, compared to the existing approach of pinging a colleague on Teams and getting the file in thirty seconds. Guess which method survived?
No feedback mechanism during launch. This is the silent killer. You launch. Some people use it. Some don't. Some try it, hit a problem, and quietly go back to what they were doing before. Without a feedback loop in those first critical weeks, adoption problems accumulate invisibly. By the time someone runs a usage report three months later, the habits are set. The window has closed. And I mean properly closed - you have roughly six to eight weeks after launch before non-adoption becomes the default behaviour that's almost impossible to reverse.
No internal champions identified before launch. I'll come back to this in detail. But the short version: the people who shape their colleagues' attitudes to a new tool aren't the ones sending the all-staff email. They're the ones answering questions in the corridor, in the Teams chat, over coffee. If you haven't identified and equipped those people before launch, you're leaving your most powerful propagation mechanism to chance.
Right, enough about what goes wrong. Four practices, none of which require additional budget - they just require treating adoption as part of the project rather than a sequel to it.
Involve end users before build decisions are finalised. And I mean genuinely involve them - not the tick-box exercise where you show people a near-finished prototype and ask if they have any feedback. I'm talking about user research that happens early enough to actually change decisions. There's a meaningful difference between research that shapes design and research that validates it. The first kind is uncomfortable because it sometimes tells you things you don't want to hear. The second kind is comfortable and largely useless.
We ran a project for a professional services firm a couple of years ago where early user research revealed that the feature the project sponsor was most excited about - a real-time dashboard for partners - was the feature partners cared least about. What they actually wanted was a simpler way to find client documents. That insight, surfaced three weeks into the project, saved months of build time and fundamentally changed what got delivered. If we'd done the research at the end, we'd have built the dashboard, launched it, watched it get ignored, and then had a very awkward retrospective.
Plan a progressive rollout from the start. Don't launch to everyone simultaneously. Identify five to ten users who meet three criteria: they're likely to adopt early, they're well-connected to their peer network, and they're willing to give you honest feedback. Launch to them first. Learn from their experience. Fix the things that trip them up. Then expand. This isn't a beta programme - it's a deliberate propagation strategy. The early group becomes your proof point, your feedback engine, and your champion network all at once.
Integrate training into the project timeline as a first-class deliverable. The training plan should be scoped alongside the technical implementation, not bolted on after it. That means training has its own workstream, its own timeline, its own owner, and its own definition of success. If your training approach is "we'll do some sessions the week before launch," you're treating the thing that determines whether users can actually use the tool as an afterthought. Which, to be blunt, it is.
Build the communication plan before launch, not after. Every stakeholder - from the board to the end users to the IT support desk - should know what's coming, why it's coming, what it means for them, and where to go for help. Before launch. Not in a scrambled email the day the tool goes live. Initiatives with structured, pre-launch communication plans are dramatically more likely to hit their adoption targets. That's not a marginal difference. That's the difference between success and failure.
If you want to build adoption into your next digital implementation from day one - with a checklist covering these four design practices, the progressive rollout approach, and the measurement setup - download the adoption planning checklist [here].
Sometimes you're reading this and the tool is already live. Adoption is low. People are worried. The instinct is to throw more training at it, or send another firm-wide email with the subject line "Reminder: please use the new system." Don't.
Diagnose which of three failure categories you're actually dealing with first, because the recovery approach is completely different for each.
Tool failure. The tool doesn't work reliably, isn't integrated with the systems users need, or has a UX problem that makes routine tasks harder than the old approach. No amount of training or communication fixes this. You need a technical intervention first. I've seen firms spend months on "adoption programmes" for tools that were fundamentally broken. It's like running a marketing campaign for a restaurant with food poisoning.
Training failure. The tool works fine, but users don't know how to use it for their specific tasks. This is different from "they attended the training session." Generic product training - here's where the buttons are - almost never translates into task-level competence. If a fee earner needs to submit a matter opening form, they need training on submitting a matter opening form. Not a 45-minute tour of the platform's features. The fix is targeted, task-specific training that maps to actual workflows.
Value proposition failure. The tool works. Users know how to use it. But the benefit to them personally isn't clear enough to justify the habit change. This is the hardest category to fix because it requires reframing, not retraining. You need to go back and articulate - clearly, specifically, in terms the user cares about - what this tool does for them. Not for the firm. For them. And sometimes, honestly, the answer is "not enough," in which case you have a more fundamental problem.
Misdiagnose which category you're in and you'll apply the wrong fix. I watched a firm spend £40k on additional training for a portal that had a two-second page load time. The training wasn't the problem. The page load was the problem. Get the diagnosis right first.
I've written a companion piece on portal adoption specifically - looking at why client portals consistently underperform and what the data actually tells us about the causes. If that's your particular headache, it's worth reading alongside this.
"How many people have logged in?" is not an adoption metric. It's a vanity metric. Someone logging in once, looking confused, and never coming back counts as a login. It tells you nothing about whether the tool is delivering value.
Set these up before launch, not three months later when someone asks how things are going.
Task completion is the one that actually matters. Are users completing the tasks the tool was designed for? If you built a portal for clients to submit documents, how many documents are actually being submitted through it versus emailed to their usual contact? This is the metric that tells you whether the tool is working as intended.
Return usage tells you whether it's been adopted. First-use completion tells you the tool works. Unprompted return usage - someone coming back the following week without being chased - tells you it's become a habit. There's an enormous gap between those two things.
Support ticket reduction is where adoption connects back to the business case. If the tool was supposed to reduce queries - fewer calls to the helpdesk, fewer "can you send me that document" emails - track whether that's actually happening.
User satisfaction is simpler than most people make it. A monthly pulse survey, three questions: Does the tool make your work easier? Would you go back to the old way if you could? What's the one thing that would improve your experience? Track the trend, not the absolute number.
Review these in your regular programme governance rhythm. Not assembled retrospectively when a board member asks whether the investment was worth it. By that point, you've already lost the ability to intervene.
This deserves proper attention because it's the single most reliable mechanism for enterprise software adoption and it's almost never deliberately implemented.
An internal champion is not someone who volunteered to be on the project team. It's not the most senior person in the department. It's someone who uses the tool well, whose opinion is respected by their peers, and who will answer questions informally - in Slack, over lunch, in the two minutes before a meeting starts. Those corridor conversations shape attitudes far more than any official communication.
Peer advocacy is the most influential factor in individual adoption decisions - more influential than executive sponsorship, formal training, or incentive structures. People trust colleagues who've used the tool and found it useful. They don't trust the project team's launch email.
Identifying the right champions requires knowledge of informal network dynamics, not just org charts. Who do people actually go to when they have a question? Who's respected as technically competent but also approachable? Those are your champions. Not the person who put their hand up in the all-hands.
Equip them properly: give them early access during the progressive rollout, provide advanced training that goes beyond the basics, and - critically - give them the context to answer the "why" questions. When a colleague says "why do I have to use this instead of just emailing Sarah?", the champion needs a good answer. Not a corporate answer. A real one.
And recognise them. In team meetings. In all-hands updates. In performance conversations. The champion role requires effort, and if it's invisible, people stop doing it. A quick mention from a senior partner costs nothing and signals that adoption matters to leadership.
Which brings me to executive sponsorship. Champions propagate adoption horizontally. But visible sponsorship from the top signals that adoption is expected, not optional. If the managing partner or COO is visibly using the tool, talking about it in meetings, referencing data from it - that sends a message no training session can replicate. If they're conspicuously not using it, that sends a different message entirely.
Adoption is not the goal. It's the mechanism by which a digital investment delivers its intended value. The goal is the business outcome - fewer support calls, faster client onboarding, better data visibility, whatever the investment was supposed to achieve. Adoption is how you get there.
This matters because it changes how you think about the entire project. If adoption is the goal, you celebrate when login rates hit 70%. If value delivery is the goal, you ask whether those 70% of users are actually completing the tasks that drive the business outcome. Those are very different questions with very different answers.
The firms I've seen get this right share a common trait. They don't treat adoption as a phase that ends. They treat it as a continuous design challenge, revisited quarterly, measured honestly, and resourced properly.
The cost of getting this wrong isn't just the wasted implementation budget. It's the cumulative erosion of confidence in digital investment across your leadership team. Every tool that gets built and abandoned makes the next proposal harder to approve, the next sponsor harder to find, the next budget harder to justify. Every tool that gets built and genuinely adopted does the opposite.
If you're about to kick off a digital implementation - a portal, a platform, an internal tool, anything that requires people to change how they work - download the adoption planning checklist [here]. It covers the four design practices, the progressive rollout approach, the measurement setup, and the champion identification criteria. Fill it in during scoping, before any build decisions get made. It won't guarantee adoption. But it'll make sure you're not leaving it to chance.
For readers in regulated industries where the change dynamics are even more complex, there's a companion piece on building momentum for change in risk-averse environments worth reading alongside this. And if you suspect the adoption challenges you're seeing are symptoms of something deeper - cultural resistance, political dynamics, ingrained habits - I've written about the biggest cultural blockers to digital progress, which might help you see the fuller picture.