How to Roll Out New Software So Employees Actually Use It

Buying software is the easy part. The hard part is the day after go live, when people have to change how they work. Many tools fail not because they are bad but because they are not used: Zylo's 2026 SaaS Management Index found the average organization uses only 54% of the licences it pays for. This guide explains how to roll out new software so that people actually adopt it, using practices that work for small and mid sized businesses without a dedicated change team.

Why adoption decides the return on software

Software delivers value only when it is used consistently for the work it was bought for. A CRM nobody updates gives no pipeline visibility. An HR system managers avoid gives no reliable records. The licence cost is the same whether the tool is used or not; the benefit is not.

The evidence on structured change is strong. Prosci asked more than 2,600 change practitioners about their projects and found that 88% of projects with excellent change management met or exceeded objectives, compared with 13% of projects with poor change management, roughly seven times more likely to succeed. Projects with excellent change management were also more likely to stay on schedule and on budget.

Key terms

• Adoption: the extent to which intended users use the software for the intended tasks.
• Change management: the structured process of helping people move from the current way of working to the new one.
• Sponsor: a senior leader who explains why the change matters and stays visibly committed.
• Champion: a respected team member who helps colleagues and passes feedback to the project team.
• Cutover: the date the new system becomes the official way of working and the old one is retired.

Managers are the deciding factor

Gallup reports that managers account for at least 70% of the variance in team engagement. The same pattern applies to software: when a manager uses the new tool, asks for updates in it and helps their team, adoption follows. When a manager keeps asking for spreadsheets, the team keeps making spreadsheets.

Development also matters. HR Dive, reporting Gallup data, notes that only 37% of US employees agreed in 2025 that they had opportunities at work to learn and grow, down from 48% in 2020. Framing training on a new tool as genuine skill development, not just compliance, can help.

The rollout plan, step by step

Step 1: Write the case for change in plain language

Before any training, answer three questions in a few sentences:

1. Why are we changing? The problem with the current way of working.
2. What will be different? What people will do differently day to day.
3. What is in it for me? The benefit for each group: less double entry, faster approvals, fewer chasing emails.

Have the sponsor share this message personally, then repeat it through managers. People need to hear the reason more than once and from people they trust.

Step 2: Equip managers first

Give managers early access, a short briefing on the why, and the specific tasks they will do in the system: approvals, reviews, reports. Ask them to use it for real before their teams start. Managers who are confident with a tool coach their teams; managers who are not quietly undermine it.

Step 3: Recruit champions

Pick one champion per team: someone respected, curious and willing to help. Give them extra training, a direct line to the project owner and a few hours a week during the first month. Champions answer the quick "how do I" questions that would otherwise become support tickets or abandoned tasks.

Step 4: Configure for the real process

Configure the tool around how work actually flows, removing fields and steps people do not need. Every unnecessary click is a reason to avoid the system. Test the configuration with a few real users before the wider rollout.

Step 5: Train on tasks, not features

Training sessions that tour every menu are forgotten within days. Instead:

• Train by role, on the three to five tasks each role does most.
• Keep sessions short, 30 to 45 minutes, and hands on.
• Provide one page guides or short screen recordings for each task.
• Schedule training close to go live, so people use what they learned immediately.

Step 6: Migrate data people trust

If people open the new system and find their data missing or wrong, trust is lost on day one. Clean and test the data before go live, and have users check a sample of their own records.

Step 7: Set a cutover date and retire the old way

Announce a date after which the old spreadsheet, inbox or system is no longer the official place for the work. Make it read only on that date if you can. Running old and new in parallel indefinitely is the most common reason adoption stalls.

Step 8: Support intensively for 30 days

Offer drop in help sessions, a dedicated chat channel and quick fixes for configuration problems. Respond to early feedback visibly; when people see their suggestions implemented, they invest in the tool.

Step 9: Measure and reinforce for 90 days

Track a few measures weekly and share progress. Recognise teams and individuals who use the tool well. Address teams that lag through their managers, focusing on removing obstacles rather than blame.

Adoption metrics to track

A 90 day timeline

Handling resistance

Resistance is information. Listen for the reason behind it:

• "I don't see why we're changing." Revisit the case for change with that person's manager.
• "It takes longer than the old way." Check the configuration; remove unnecessary steps.
• "I don't know how." Offer one to one help from a champion.
• "My manager still asks for the spreadsheet." Fix it with the manager, not the employee.

A communication plan you can copy

Repeat key messages through different channels and people. A simple plan for a small business:

A training plan by role

The role of HR in software rollouts

HR teams are often well placed to support adoption, even for tools outside HR. They can build training into onboarding so new joiners learn the tool from day one, include tool skills in role expectations where relevant, and use engagement or pulse surveys to spot teams that are struggling. Treating the rollout as part of employee development, rather than an IT announcement, changes how people experience it.

Sustaining adoption after 90 days

Adoption can slip once the launch energy fades. Keep it healthy by:

• Reviewing usage measures monthly for the first year.
• Adding the tool to onboarding for every new hire.
• Refreshing the one page guides when the vendor changes the interface.
• Collecting improvement ideas and implementing a few each quarter.
• Removing seats from people who no longer need them, so licences match real use.

Worked example: rolling out a CRM to a 25 person sales team

This illustrative plan shows the steps above applied to a common rollout.

The case for change. Deals are tracked in personal spreadsheets, so managers cannot see the pipeline, and handovers lose context when people are away. The CRM gives everyone one view of every deal and cuts the Friday forecast spreadsheet.

Managers first. The three sales managers get access four weeks early, set up their own pipeline views and run one week's forecast meeting from the CRM before their teams join.

Champions. One experienced salesperson per team gets extra training and a weekly half hour with the project owner.

Configuration. Only the fields used in forecasting are required; everything else is optional. The deal stages match the stages the team already uses.

Data. Each salesperson checks their imported deals in a 20 minute session the week before go live.

Training. Two 40 minute sessions per team: one on daily deal updates, one on using the CRM on mobile after customer meetings.

Cutover. From the go live date, the forecast meeting uses only the CRM. The old spreadsheets are archived two weeks later.

Measures. Weekly active users, share of deals with a next step and close date, and whether the forecast meeting runs entirely from the CRM.

Checklist before go live

• The case for change has been shared by the sponsor and repeated by managers.
• Managers have used the tool for real work.
• Champions are named and trained.
• Configuration has been tested with real users.
• Data has been migrated and checked by its owners.
• Role based training is scheduled within a week of go live.
• A support channel and drop in sessions are ready.
• The cutover date for the old process is announced.
• Adoption measures and a dashboard are set up.

Using pulse surveys well

Short pulse surveys at weeks two and eight tell you how the rollout feels, not just whether people log in. Keep them to five questions or fewer, for example:

1. I understand why we changed to the new tool. (agree or disagree scale)
2. I can complete my main tasks in the new tool without help.
3. The new tool saves me time compared with the old way.
4. I know where to get help when I am stuck.
5. What is the one thing that would make the tool easier to use? (open text)

Share the results with the team and say what you will change in response. Acting visibly on the feedback is what keeps people answering, and it often reveals configuration problems faster than support tickets do.

Common mistakes

• Announcing the tool by email and expecting adoption to follow.
• Training everyone on everything, once, weeks before go live.
• Leaving managers to learn alongside their teams.
• Running the old and new systems in parallel with no end date.
• Measuring logins but not whether the work actually moved.

Next steps

Plan adoption before you sign, not after. Include rollout effort in your total cost of ownership, test usability with real users during your vendor evaluation, and use the 90 day plan above from the first day. The software you buy is only as good as the way your people use it.