I have sat in project steering committees for over two decades, and the conversation often follows the same arc. Months go into requirements, architecture, security, testing and integrations. Then, about three weeks before launch, somebody says: "We should probably think about rollout."
The adoption plan, which helps determine whether the investment creates value, gets compressed into two pages and handed to somebody in operations who was absent from the preceding decisions.
It is like building a restaurant with a world-class kitchen, hiring brilliant chefs and sourcing remarkable ingredients, then forgetting to put a door on the front.
The common response is that training will happen after launch. That treats adoption as a finishing coat. Training and change management matter, while neither can compensate for a tool designed without the behaviour, incentives and working conditions of the people expected to use it.
Adoption is a design requirement. It belongs beside functionality, security and service operation from the start.
Define adoption before you chase it
"Get people using the platform" is too vague. Name the behaviour that creates value and the group expected to perform it.
For a client portal, the behaviour might be a client securely uploading a requested document and returning to see its status. For a knowledge system, it might be a consultant finding and reusing an approved proposal component. For a CRM, it might be a relationship owner recording a meaningful next action while the context is fresh.
This definition stops a login being mistaken for success. It also exposes a harder question: does the desired behaviour make sense for the user? If the portal adds steps, the knowledge result is unreliable or the CRM record serves only a management report, resistance may be rational.
Write the adoption hypothesis in plain language:
We expect this group to perform this task in this situation because it improves this part of their work. That behaviour should contribute to this service or business outcome.
Each part can be researched and tested. If the team cannot complete the sentence, it is too early to rely on a communications plan.
Five ways adoption gets designed out
Failure rarely has one cause. These problems frequently reinforce one another.
There is no useful first experience. A launch email provides credentials and leaves the user at a blank dashboard. The first session should help the person complete one relevant task, understand the result and know what to do next. A tour of every feature increases cognitive load without building competence.
The user-side value is missing. The business case talks about efficiency, consolidation and management information. None explains why a busy client or colleague should change behaviour on Tuesday afternoon. State what becomes easier, safer, faster or clearer for them, and make sure the product actually delivers it.
The new route loses to the workaround. A professional-services firm had built an impressive knowledge system, but finding a document required several clicks and a filter. Asking a colleague in Teams often produced the file faster. The workaround survived because it solved the immediate job with less effort.
Feedback arrives too late. People try the tool, hit a problem and return to the old method. A report reviewed months later shows low use but loses the context. Put observation, support and user feedback close to the first attempts so the team can distinguish confusion, defects and missing value.
Informal influence is ignored. Attitudes form through colleagues as well as official communications. If respected peers encounter problems or cannot explain the purpose, scepticism spreads quickly. Identify those people early and involve them in shaping the experience.
Design adoption during the build
Involve users while decisions can still change
Showing a nearly finished prototype and requesting comments is validation at best. Research should happen while the team can still change scope, workflow and priorities.
On one professional-services project, early research showed that partners cared less about the sponsor's proposed real-time dashboard than about finding client documents with less effort. That insight redirected the build before the more elaborate feature consumed the programme.
Good involvement also includes the people who support and govern the service. Operations sees exceptions. Risk and compliance can identify obligations that affect the journey. IT support knows where similar tools fail. Accessibility needs and assistive-technology use need direct attention. The objective is a workable service, rather than consensus on every design choice.
Plan a progressive rollout
A smaller first group can expose issues before they affect everybody. Choose people who represent meaningful workflows and constraints, including some who are sceptical or less technically confident. A pilot made entirely of enthusiasts produces flattering evidence.
Define what the group will test, what evidence will determine expansion and which risks require a pause. Fix serious defects and workflow gaps. Avoid turning the first users into permanent unpaid testers while the launch date remains immovable.
Progressive rollout is not suitable for every change. A mandatory security control or tightly connected system switch may require a coordinated cutover. Even then, rehearsals, representative testing and stronger support can apply the same learning principle.
Treat enablement as a product deliverable
Training should map to tasks and roles. A fee earner who needs to open a matter requires practice opening a realistic matter, including exceptions and recovery from errors. A tour of menus will not create that competence.
Decide who needs live instruction, who needs guidance in the flow of work and who needs a simple reference. Give managers and support colleagues the context to reinforce the change. Test whether users can complete important tasks, rather than counting attendance.
Training also creates evidence for design. If many capable people need extensive instruction for a frequent, simple task, simplify the task before expanding the course.
Prepare the service around the launch
Every affected group should know what is changing, when, why and where to get help. Tailor the message to its role. The board needs the outcome and decision thresholds. Managers need to understand local disruption and expectations. Users need the first action and benefit. The support desk needs diagnostic information and escalation routes.
Plan capacity for the early period. Monitor critical journeys, not merely system uptime. Give frontline teams a fast way to report patterns. Decide who can pause the rollout if the experience is unsafe or damaging.
If you want a practical structure for this work, download the adoption planning checklist below. It covers the adoption hypothesis, early involvement, rollout, enablement and measurement.
When adoption is already low, diagnose first
Sending another all-firm reminder is rarely a diagnosis. Separate at least four possible failures because they require different responses.
Product failure. The tool is unreliable, poorly integrated, inaccessible or makes routine tasks harder. Repair the experience or reconsider the product. More persuasion will consume trust.
Capability failure. The tool supports the task, but people do not know how to perform it in their context. Provide task-specific practice, prompts and support. Check whether the difficulty reveals a design problem too.
Value failure. People can use the tool and see too little benefit to change an established habit. Revisit the proposition and the workflow. Sometimes the answer is that the product does not create enough user value. That finding should change the investment, rather than the tone of the launch email.
Environment failure. The surrounding organisation rewards the old behaviour or makes the new one impractical. A manager asks teams to use the CRM while continuing to accept private spreadsheets. A portal exists, yet relationship partners invite documents by email. Measures, policies, leadership behaviour and system defaults may all contradict the stated change.
Interview people who adopted, tried and stopped, and never started. Observe representative tasks. Look at support contacts, errors, completion paths and the old channels still in use. The categories can overlap; the point is to avoid treating every cause with training.
The companion piece on client portal adoption explores this diagnosis in a specific external-user context.
Measure meaningful use and value
Set measures before launch so there is a baseline and a proportionate way to collect data. Avoid turning surveillance of employees or clients into another adoption cost. Use only the data that is necessary, explain its purpose and apply appropriate governance.
Task completion asks whether people complete the jobs the tool was designed for. For a document portal, compare successful secure submissions with documents still arriving through other routes. Include failure and abandonment, rather than just completed events.
Return behaviour can show whether use persists when the task recurs. Interpret it in context. A person should not return weekly to a service they need annually.
Time, effort and exceptions reveal whether the new process reduces work or moves it somewhere less visible. Measure repeated entry, manual intervention, support demand and time to resolution across the whole service.
User confidence and experience need qualitative evidence. A short pulse can track direction, but conversation and observation explain the score. Ask what became easier, where people lost confidence and what would make them choose the old route.
Business or service outcome closes the chain. Did onboarding become faster without reducing review quality? Did approved knowledge get reused without spreading outdated material? Did data become more complete enough to support the intended decision?
Review leading evidence frequently during rollout and outcome evidence over a period that suits the behaviour. Pre-agree what would trigger a design change, more support, an expansion or a pause.
Use champions without outsourcing the change to them
An internal champion is usually a respected peer who can use the tool, answer questions in the language of the work and feed problems back to the team. They may influence attitudes in the two minutes before a meeting more effectively than an all-staff email.
Choose champions through observation and conversations, not seniority or a request for volunteers alone. Include different roles and locations. Give them early access, deeper task knowledge, a direct support route and enough context to explain why the change exists.
Set boundaries. Champions should not become a free helpdesk or carry accountability that belongs to product and leadership teams. Recognise the time involved and incorporate their evidence into decisions. If the same question reaches every champion, improve the product, guidance or communication at source.
Visible sponsorship matters too. Leaders signal priorities through what they use, ask about and allow. A partner who requests a private spreadsheet after telling everybody to use the shared system weakens the change in one move. Sponsorship should model the expected behaviour and remove organisational obstacles, rather than deliver a launch speech and disappear.
Adoption is a mechanism
Adoption is a route to value, rather than the destination. A high login rate can coexist with incomplete tasks, duplicated work and worse outcomes. Compulsory use can produce compliance without confidence.
Return to the adoption hypothesis. Are the intended people completing the meaningful task? Is the experience good enough to sustain that behaviour? Is the behaviour contributing to the service outcome? If one link fails, investigate it.
The cost of getting this wrong extends beyond one implementation budget. Each tool launched and abandoned erodes confidence in the next digital proposal. A product that earns sustained use does the opposite.
If you are about to start a portal, platform or internal tool that asks people to work differently, download the adoption planning checklist below and complete it during scoping. It will not guarantee adoption. It will make the assumptions, responsibilities and evidence visible while there is still time to improve the design.
For readers in regulated industries, the companion piece on building momentum in risk-averse environments examines the additional change constraints. If adoption problems appear rooted in cultural resistance, political dynamics or ingrained habits, the article on cultural blockers to digital progress provides a broader view.
