Adoption After Purchase: Making a Tool Stick

The contract is signed. The accounts are created. An email goes out: "We now have a new tool, here is the link." Two weeks later, a handful of enthusiasts use it daily, most people have logged in once and a stubborn group carries on with the old spreadsheet. By the renewal date, the tool is a line in the budget that nobody can quite justify.

This is the usual fate of software purchases, and it is avoidable. The reason is rarely the tool. It is that purchase is treated as the end of the project instead of the beginning. This guide offers a practical plan for the first ninety days after you buy, based on the idea that adoption is something you do, not something that happens.

What adoption means

Adoption is not that people have accounts. It is that they use the tool, for the purposes you bought it, in a way that delivers the benefit you expected.

Write your own definition before the tool arrives.

• Who should be using it?
• For what tasks?
• How often?
• What should stop being done the old way?
• What result will show it is working?

Without a definition, you cannot tell success from drift.

Why adoption fails

Change management, the discipline of helping people and organisations through change, has long observed that technical solutions fail more often from human causes than technical ones. Common reasons:

• No clear reason. People are told to use it, not why.
• No owner. Nobody is responsible for making it work.
• Poor onboarding. People are left to figure it out.
• Old and new in parallel. Two ways of working, and the old is easier.
• No visible leadership use. Managers ask for reports from the old system.
• Wrong fit. The tool does not match how people work.
• Bad timing. Launched in the busiest week.
• No feedback loop. Problems go unheard.

Each is fixable if you see it early.

Appoint an owner and champions

An owner is a named person responsible for adoption. They have time set aside, authority to make decisions about configuration and the ear of senior people.

Champions are respected people in each team who understand the tool, help colleagues and report back. Choose them for credibility, not just enthusiasm. A thoughtful sceptic who becomes a supporter is worth ten cheerleaders.

Keep the group small and meet briefly every week or two during the first ninety days.

Before launch: prepare

Do the groundwork before announcing.

Configure the tool for your workflow. An empty tool is hard to adopt. Set up fields, statuses, templates and permissions in line with your requirements.

Bring in the data, or the minimum needed to begin real work.

Connect the integrations people expect.

Set up single sign-on and security properly, so that nobody has to work around it.

Write the "why". One paragraph: what problem this solves, what changes and what stays the same.

Plan the cut-over. When does the old way stop? Parallel running should be short and have an end date.

Prepare materials: a short guide, a video or two, answers to likely questions, a place to ask for help.

Check accessibility. Make sure the tool works for everyone on the team, including anyone who uses assistive technology. Fix or provide alternatives before launch, not after complaints.

Pick the date well. Avoid your busiest period.

Days 0 to 30: start well

The announcement

Make it from a leader, and make it human.

• Why you chose this tool and what problem it solves.
• What changes and when.
• What support is available.
• Who to ask.
• A thank-you to the pilot group, if there was one.

Onboarding

Onboarding is the process of helping new users become productive. Make it easy and short.

• A thirty-minute live session per team, built around their real tasks, not a feature tour.
• A one-page quick start with the first three things to do.
• A sandbox or sample data for safe practice.
• Office hours, a regular slot when anyone can drop in with questions.
• Champions on hand for the first week.

Teach the first task well. People remember one good experience more than ten features.

Make the old way harder

If both ways remain open, the old one wins. Set a date after which the old process is no longer used.

• Move the live data.
• Redirect requests to the new place.
• Ask managers to request reports from the new tool.
• Archive the old system as read-only.

Do it fairly, with notice and support.

Gather early feedback

In the first week, ask every team: what is working, what is confusing, what is missing? Short, informal, anonymous if needed. Fix quick issues fast and say you did.

Days 31 to 60: build habits

By now the novelty is wearing off. This is where tools quietly die.

Check usage. Look at who is active and who is not. Active means doing the core tasks, not just logging in.

Talk to non-users. Not to scold, but to understand. Is it the tool, the training or the workload?

Share small wins. "Last month's report took ten minutes instead of half a day." Real examples from real colleagues.

Adjust the configuration. Remove fields nobody uses, add the one everyone asks for, simplify.

Retrain where needed. A second, shorter session focusing on what people are struggling with.

Fit it into routines. Use the tool in regular meetings: review the board together, open the dashboard, assign actions inside it.

Keep leaders visible. When managers use the tool and ask others to, the signal is clear.

Days 61 to 90: lock in and review

Measure against your definition. Are the right people using it for the right tasks, at the right frequency?

Compare with the baseline. Time on key tasks, error rates, requests handled, satisfaction.

Review the plan. What worked? What did not? What would you do differently?

Document the way of working. A short, living guide to how your team uses the tool.

Set up ongoing ownership. Who handles new starters, permissions, configuration changes and vendor contact?

Decide on next steps. More features? More teams? Or leave it as is?

Check the contract. Note the renewal and notice dates. If adoption is poor, you have time to act before the notice deadline.

Measuring adoption honestly

Logins are a weak measure. Better measures:

• Active users performing a core action in a period.
• Depth of use: the share of key features in use.
• Time to complete key tasks, against baseline.
• Share of work done in the tool, rather than elsewhere.
• Support requests, and their themes.
• User satisfaction, from a short survey.

Cohort analysis, the practice of following groups of users who started at the same time, helps: compare how the first teams behaved with how later teams do. If later cohorts adopt faster, your onboarding is improving.

Share the numbers with the team. People take adoption seriously when it is visible.

Handling resistance

Resistance is information.

Listen. Ask what is hard. There may be a real gap: a missing feature, an awkward step, an accessibility problem.

Respect workload. Learning something new takes time that busy people do not have. Make time.

Acknowledge loss. People may be attached to the old way, or worried about their skills.

Show benefit to them, not just to the organisation.

Avoid blame. Treat slow adopters as colleagues needing help.

Escalate gently. If the tool is required for a legitimate reason, say so and support people through it.

When it is not working

Sometimes, despite your best efforts, adoption stalls. Ask honestly:

• Is the tool a poor fit?
• Did our requirements miss something?
• Is the training failing?
• Is the timing wrong?
• Is the problem the process, not the tool?

You may fix it, scale it back or decide to leave at the next renewal. A tool that cannot be made to work is a sunk cost, and continuing to pay for it adds to the loss. Having notice dates in your diary keeps that option open.

A one-page adoption plan

• The definition of adoption.
• The owner and champions.
• The "why" paragraph.
• The cut-over date for the old way.
• The onboarding sessions and materials.
• Check-ins at thirty, sixty and ninety days.
• The measures and targets.
• The review date and contract notice date.

Common mistakes

• Treating the purchase as the end.
• No owner.
• A feature tour instead of real tasks.
• Running old and new in parallel for ever.
• Measuring logins.
• Ignoring feedback.
• Forgetting the contract dates.

On this site

The categories and search pages help you find tools, the launches page shows new entrants and the contact page reaches a person. The blog has more guides for buyers and teams.

The short version

Purchase is the start. Define adoption, appoint an owner and champions, configure the tool for your workflow and explain why. In the first month, onboard around real tasks and set a date to retire the old way. In the second, build habits, check use and adjust. In the third, measure against your baseline, document the way of working and decide next steps, keeping the contract dates in view. Listen to resistance, because it often points to real problems.