Change Management: Getting Your Team to Actually Use New Tools

You paid for the new project management platform, the CRM or the shared document system.

The launch email went out, everyone attended the training session and the licences are active. Three months later, half the team is still tracking work in spreadsheets, the new tool contains a fraction of the data it should and a few people quietly ask whether the old way could come back.

This is one of the most common and expensive problems in digital transformation. The software usually works. What fails is adoption: the shift from people having access to a tool to people relying on it as part of their normal work.

Getting a team to actually use new tools comes down to a handful of things done well. The tool has to solve a problem your team recognises and make their work easier, not just management's. People need to understand why the change is happening and what it means for them personally. They need practical, role-specific help at the moment they need it, not one long training session. Managers and respected peers have to use and champion the tool visibly. The old way of working has to be retired on a clear date. And adoption needs to be measured by real behaviour, not logins.

This guide explains each of these, why they matter, and how a small or mid-sized business can apply them without a dedicated change management department.

Why teams do not adopt new tools

You will often read that 70 percent of change programmes fail. It is worth knowing that this figure has a shaky foundation. In a 2011 paper in the Journal of Change Management, Mark Hughes traced the claim back through the literature and found no valid empirical evidence supporting a single failure rate. Consultancy surveys, such as McKinsey's research on organisational transformations, do consistently report that only a minority of large transformations fully achieve their goals, but success is defined and measured differently in each study.

The more useful question is not how often change fails, but why. For new tools, the reasons are remarkably consistent.

The first is that the tool does not seem useful to the people expected to use it. In 1989, Fred Davis proposed the Technology Acceptance Model, which suggests that people's intention to use a technology depends largely on two perceptions: whether it will help them do their job better, and how easy it is to use. Decades of research have built on that model. Its practical lesson is simple. If staff see a new tool as extra admin that mainly benefits management reporting, they will avoid it, however good the features look in a demo.

The second is the pull of existing habits. Behavioural economists William Samuelson and Richard Zeckhauser described status quo bias, the tendency to stick with current arrangements even when alternatives may be better. Familiar spreadsheets and email threads feel fast because people already know them, and the new tool feels slow because they do not. That gap is real during the first weeks, and if nobody plans for it, people retreat to what feels efficient.

The third is that the old way is still available. When people can choose between the familiar system and the new one, many will keep choosing the familiar one, particularly under deadline pressure.

The fourth is inadequate support. A single training session before launch, followed by silence, leaves people stuck the first time they hit a real problem. Without help close at hand, they find workarounds.

The fifth is mixed signals from leadership. If managers ask for updates by email, review numbers in the old spreadsheet or never open the new tool themselves, the team concludes that the change is optional.

None of these is a technology problem. That is why the solution is change management: the structured work of helping people move from the current way of working to the new one.

Before rollout: pick the right problem and involve the people who will use it

Adoption is decided long before launch day. The choices made while selecting and configuring a tool have more influence on whether people use it than anything that happens afterwards.

Start from a problem the team feels

A tool introduced to solve a problem the team already experiences has a natural head start. If account managers regularly lose track of client requests, a shared system that prevents that is welcome. If the main reason for the change is that leadership wants better reporting, the team will see only the extra work.

The practical step is to describe the change in terms of the problems it fixes for each group of users, and to check those problems with the people concerned. Ask them what slows them down today, where information gets lost and what they would most like to stop doing. If you cannot describe a benefit for a group of users in their own words, expect resistance from that group.

Involve users in selection and setup

Involving a few representative users in choosing and configuring the tool has two benefits. They catch practical problems early, such as a field that makes no sense for their work or a workflow that adds unnecessary steps. And they become invested in the outcome. Research by Michael Norton, Daniel Mochon and Dan Ariely on what they called the IKEA effect found that people tend to value things more when they have helped create them. A team member who helped design the new workflow is far more likely to defend it.

This does not mean everyone gets a vote on every setting. It means the people who will live with the tool every day have a real say in how it fits their work.

Configure for simplicity first

Most modern business tools can be configured in countless ways, and there is a strong temptation to replicate every existing process and report from day one. Resist it. Launch with the essential workflows set up well, remove fields and options nobody needs, and add complexity in later phases once the basics are established. Ease of use is the second pillar of the Technology Acceptance Model for a reason: every unnecessary click is a small reason to go back to the old way.

Decide what will be retired, and when

Before launch, decide which old systems, spreadsheets or habits the new tool replaces, and set a date when they will stop being used. Without this decision, you will end up running two systems in parallel indefinitely, which doubles the work and guarantees that neither is fully trusted. (Internal link suggestion: a guide to choosing business productivity software or mapping business processes before digitising them.)

Making the case people actually care about

Announcing a new tool is not the same as making the case for it. People adopt change more readily when they understand why it is happening, believe it is worth the effort and know what is expected of them.

Use a simple model to check you have covered the basics

Several established change models can help, and two are especially practical for tool rollouts. John Kotter's eight-step model, first published in the Harvard Business Review in 1995, emphasises creating urgency, building a guiding coalition and generating short-term wins. Prosci's ADKAR model focuses on the individual and describes five outcomes each person needs to reach: Awareness of the need for change, Desire to take part, Knowledge of how to change, Ability to work in the new way and Reinforcement to make the change stick.

ADKAR is particularly useful as a diagnostic. When someone is not using the new tool, you can ask which of the five is missing. A person who does not understand why the change is happening needs a different response from someone who agrees with it but has not yet learned how to do a particular task. Many rollouts focus almost entirely on knowledge, through training, while neglecting awareness and desire. Prosci's own benchmarking research reports that projects with excellent change management are several times more likely to meet their objectives than those with poor change management, which, while coming from an organisation that sells change management, is consistent with what most practitioners observe.

Explain the why in concrete terms

Vague statements such as "this will improve collaboration" or "we are modernising our systems" rarely persuade anyone. Specific ones do. "At the moment, it takes us an average of two days to find out whether a customer has paid, because the information is spread across three spreadsheets. With the new system, you will see it on the customer record" is a reason people can understand and check.

Be honest about the costs as well. Learning a new tool takes time, and the first few weeks will probably feel slower. Saying so openly builds trust and makes the initial dip less discouraging when it arrives.

Answer "what is in it for me?" for each role

Different people experience the same change differently. A salesperson may care about spending less time on admin. A manager may care about seeing the pipeline without chasing updates. An operations lead may care about fewer errors. Tailor the message to each group, ideally with an example from their own work.

The message should come from the right people. Research on change communication consistently suggests that employees prefer to hear about organisational changes from senior leaders, and about how changes affect them personally from their own manager. A short message from leadership explaining why, followed by team-level conversations about what it means day to day, usually works better than a single company-wide email.

Champions, early adopters and the role of managers

People take far more notice of what their colleagues and managers actually do than of what a launch email tells them. A rollout that builds visible support inside teams spreads much faster than one driven entirely from the top.

Not everyone adopts at the same pace

Sociologist Everett Rogers, in his book Diffusion of Innovations, described how new ideas spread through groups in a predictable pattern. A small group of innovators and early adopters tries new things first, followed by an early majority, a late majority and finally a group Rogers called laggards, who adopt last or not at all. The labels were developed for innovations spreading through whole societies, but the general pattern is familiar in workplaces too: some people will be enthusiastic in week one, most will wait to see whether the tool works for others, and a few will resist for as long as they can.

The practical lesson is not to treat everyone the same. Use the enthusiasts to prove the tool works and to help others. Focus your main effort on the large middle group, who will move once they see colleagues benefiting. Handle the most resistant individually rather than letting them set the tone.

Build a champion network

Champions are respected team members who learn the tool early, use it visibly and help colleagues. A good champion is not necessarily the most technical person, but someone others already go to for advice. Aim for at least one in each team or location.

Give champions early access, extra training, a direct line to whoever configures the tool and a little protected time to support others. Ask them to collect feedback and recurring problems. In return, recognise their contribution openly. Champions often do more to drive adoption than any formal training programme, because help from a peer at the desk next to you is quicker and less intimidating than raising a ticket.

Make managers role models

Managers have more influence on adoption than anyone else, because they decide what their team spends time on and how work is reviewed. If a manager runs the weekly meeting from the new project board, asks for updates in the new tool and stops accepting status reports by email, the team adapts quickly. If the manager keeps using the old methods, the team will too.

Brief managers before their teams, give them a clear explanation of what they are expected to do differently and check in with them regularly during the rollout. A short conversation with a manager who is quietly undermining the change usually achieves more than any number of reminder emails to the team.

Training that sticks

The standard approach to training, a single session shortly before launch covering every feature, is one of the least effective ways to help people learn a tool.

Why one-off training fades

In the 1880s, the psychologist Hermann Ebbinghaus studied how quickly people forget information they have memorised, and described what became known as the forgetting curve: without reinforcement, much of what we learn is lost within days. His experiments used nonsense syllables rather than software, and later research has refined the picture considerably, but the core finding is widely accepted. Information that is not used or revisited fades fast. A feature demonstrated two weeks before someone first needs it will probably have been forgotten by the time it matters.

Make training role-based and task-based

People do not need to know everything the tool can do. They need to know how to complete the specific tasks in their own job. Build training around real workflows for each role, such as "how to log a new client enquiry" or "how to submit an expense claim", using realistic examples from your own business rather than the vendor's generic demo data. Short sessions for each group are more effective than one long session for everyone.

Provide help at the moment of need

The most valuable support arrives when someone is stuck on a real task. Practical options include short how-to guides or videos for common tasks, kept in one easy-to-find place, a dedicated chat channel where people can ask questions and get quick answers, drop-in sessions or "office hours" during the first few weeks, and champions available on the floor or online. For larger rollouts, digital adoption platforms such as WalkMe, Whatfix or Pendo can add in-app guidance and walkthroughs, although for many smaller businesses simpler methods work perfectly well.

Reinforce over time

Plan follow-up after launch. A short refresher two or three weeks in, once people have real questions, is often more useful than the original training. Share quick tips regularly, highlight useful features once the basics are established and update guides when you change the configuration. Learning is spread across the first months, not concentrated on day one. (Internal link suggestion: a guide to employee onboarding for new software or creating internal knowledge bases.)

Designing the rollout

How you introduce a tool shapes first impressions, and first impressions are hard to change. A well-designed rollout limits early frustration and builds momentum.

Start with a pilot

For most tools, begin with a pilot group, ideally a team that is open to change, has a clear use for the tool and includes at least one strong champion. Run the pilot for long enough to cover a full cycle of the relevant work, often two to six weeks. Use it to fix configuration problems, refine training materials, collect real examples of benefits and build a set of answers to common questions. A successful pilot also gives you credible stories to share with the rest of the organisation.

Roll out in phases

After the pilot, expand in stages rather than switching everyone at once, unless the tool only works when everyone uses it together. Phasing lets support resources focus on one group at a time and allows you to improve the process between waves. Choose the order deliberately. Teams that are enthusiastic and whose work most clearly benefits often make a good second wave, because their success helps convince others.

Migrate the right data

People will not trust a new system that is missing the information they need. Before each group moves, make sure the relevant data, such as active projects, open customer records or current documents, is in the new tool and accurate. Leave out obsolete information rather than importing everything and cluttering the new system.

Switch off the old way

This is the step most organisations hesitate over, and it is often the one that decides success. Once a group has moved and has support in place, retire the old system or process on the date you set. That might mean making old spreadsheets read-only, archiving old shared folders, closing the old ticketing inbox or no longer accepting reports in the old format. Keep access to historical data where it is genuinely needed, but stop new work happening in the old place. As long as the old way is available and familiar, many people will keep using it.

Celebrate early wins

Share specific examples of the tool making a difference as soon as they appear: a project delivered on time because tasks were visible, a customer issue resolved faster, an hour a week saved on reporting. Kotter's model highlights short-term wins for good reason. They provide evidence that the change works and give the hesitant majority a reason to commit.

Handling resistance

Some resistance is normal, and much of it is useful. People who push back often understand the details of the work better than those who chose the tool, and their objections can reveal real problems before they become expensive.

Listen before persuading

When someone resists, find out why. The reasons usually fall into a few categories: the tool genuinely does not fit part of their work, they do not see the benefit, they are worried about looking incompetent while they learn, they are concerned about being monitored, or they are simply overloaded and the change has arrived at a bad time. Each needs a different response, and you cannot choose the right one without asking.

Fix genuine problems quickly

If resistance points to a real flaw, such as a missing field, a confusing workflow or an integration that does not work, fix it and tell people you have done so. Few things build trust faster than visible responsiveness. Few things destroy it faster than dismissing a valid complaint as resistance to change.

Address fears directly

New tools sometimes create anxiety that is rarely voiced. Experienced staff may worry that struggling with new software will undermine their standing. Others may be concerned that activity tracking will be used to judge them unfairly. Be clear about how data from the tool will and will not be used, and make it safe to ask basic questions. Pairing less confident users with patient champions often helps.

Be clear about expectations

Listening does not mean the change is optional. Once concerns have been heard and reasonable adjustments made, be clear that the new tool is now how the work is done. Managers should address persistent non-use in the same way they would any other expectation of the role: privately, specifically and with support offered.

Manage the workload during transition

Learning a new tool takes time and attention. If people are expected to keep up their full workload while also learning a new system, the new system will lose. Where possible, time rollouts away from busy periods and reduce other demands during the first few weeks.

Measuring real adoption

If you do not measure adoption, you will not know whether it is happening until the problems become obvious. The challenge is to measure behaviour that reflects genuine use, not just activity.

Go beyond logins

Logins and licence counts are the easiest numbers to find and the least meaningful. Someone who logs in once a week to look at a dashboard is not using a CRM in the way it was intended. Better measures focus on the core actions the tool exists to support. For a CRM, that might be the share of deals and customer interactions recorded in the system. For a project management tool, the share of active projects with up-to-date tasks and owners. For a shared document system, the proportion of team documents created and edited there rather than sent as attachments.

Watch the old system too

One of the clearest signs of adoption is declining use of whatever the tool replaced. If the old spreadsheet is still being updated every day, or internal email volume on a topic has not fallen, the new tool has not yet become the default.

Measure outcomes, not just usage

Ultimately, the tool was introduced to improve something. Track the business outcome you identified at the start, such as faster response times, fewer missed deadlines, less time spent on reporting or more accurate forecasts. If usage is high but outcomes have not improved, the tool may be configured badly or used in the wrong way.

Ask people how it is going

Numbers tell you what is happening. Short pulse surveys and conversations tell you why. A few simple questions, such as how easy the tool is to use for your main tasks, whether it saves or costs you time and what would make it more useful, asked at intervals during the first few months, will surface problems that usage data cannot show.

Review regularly and act

Review adoption data with team leads every couple of weeks during rollout, then monthly. Look for teams or individuals who are falling behind and find out why, using the ADKAR questions as a guide. Adoption rarely improves on its own once it stalls, but targeted support for the right group usually moves it quickly.

Common mistakes that sink adoption

Treating launch day as the finish line. The real work of adoption happens in the weeks and months after launch. Budget time and attention for that period, not just for setup.

Buying for features rather than fit. A tool with impressive capabilities that do not match how your team works will be harder to adopt than a simpler one that fits naturally. Judge tools by how well they handle your most common daily tasks.

Rolling out too many changes at once. Introducing a new CRM, a new project tool and a new communication platform in the same quarter overwhelms people. Sequence changes so each one has time to settle.

Letting the configuration grow unchecked. Every team requests one more field, one more status and one more report. Over time, the tool becomes cluttered and slow to use. Assign an owner who reviews changes and keeps the setup simple.

Ignoring integrations. If people have to copy information between the new tool and other systems by hand, they will resent it. Where possible, connect the new tool to email, calendars and the other systems your team relies on, so information flows automatically.

Leaving no one in charge after go-live. A tool without an owner degrades. Permissions drift, outdated data piles up and nobody updates the guides. Make ongoing ownership part of someone's role.

When a business is introducing several tools as part of a wider digital transformation, the people side of the change often needs as much planning as the technology. An experienced digital transformation partner can help map processes, configure tools around how your team actually works and plan a rollout that builds adoption rather than relying on it.