✦ Sales assets
Getting your team to actually use the new system
User adoption of new software usually fails quietly - people keep the spreadsheet running alongside the new system rather than raising an objection. Here's what actually drives adoption, and it starts well before launch day.
Haystak · 11 August 2026 · Updated 11 August 2026 · 8 min read
User adoption of new software is treated as a training problem after the fact, when the real drivers are decided earlier: whether the people doing the work were involved in shaping it, whether it's genuinely faster than what it replaces, and whether leadership visibly uses it themselves.
A technically excellent system with poor adoption delivers none of the value it was built for. This is as much a project risk as a bad requirements document, and it deserves the same planning.
Why adoption actually fails
- The people doing the work weren't consulted, so the system reflects how management thinks the process works, not how it actually happens - see business process mapping for why the gap between the two is usually bigger than expected.
- It's slower than the old way for at least one common task, even if it's faster overall - people remember the friction, not the average.
- There's no clear moment the old system stops being available, so the new one becomes optional and the workaround wins by default.
- Leadership doesn't use it themselves, or visibly routes around it for anything that matters, which tells everyone else what's really expected.
- Training happened once, at launch, for people who weren't ready to absorb it yet.
What actually drives adoption
| Driver | What it looks like in practice |
|---|---|
| Early involvement | The people who'll use it daily test it before launch, and their feedback visibly changes something |
| A genuine speed win | At least one task everyone does often is faster, not just theoretically better overall |
| A hard cutover | The old system or spreadsheet is switched off on a set date, not left running 'just in case' |
| Visible leadership use | Managers use the system for the same tasks they ask staff to use it for |
| Ongoing, staged support | Training and support continue for weeks after launch, not just on day one |
Plan adoption before the build, not after
The best adoption work happens during discovery, not at launch. If the people who'll use the system daily were interviewed while it was being scoped, and their real workarounds were mapped rather than assumed away, the system is far more likely to fit how they actually work - which is most of the adoption battle before a single training session happens.
This is also where how to write a software brief connects directly to adoption: a brief written entirely by management, without input from the people doing the work, tends to produce a system that's technically correct and practically unloved.
A staged rollout plan
- 01Pilot with a small, willing group before a full rollout - real feedback from real use, before the whole company is watching.
- 02Fix what the pilot surfaces, visibly, and tell the pilot group what changed because of their feedback.
- 03Set and communicate a hard cutover date for the old system, well in advance.
- 04Train in short sessions close to when people will actually use each feature, not one long session covering everything at once.
- 05Check in at two and six weeks post-launch, not just at launch - most abandonment happens quietly in this window, not on day one.
What to do when adoption still struggles
If people are still avoiding the system a month after a well-planned rollout, resist the urge to mandate compliance before understanding why. Usually there's a specific task that's genuinely worse than before, and fixing that one thing does more for adoption than any policy memo.
Poor adoption is sometimes a sign the system doesn't match the real process rather than a training gap - worth revisiting against business process mapping before assuming it's a people problem.
If you're planning a rollout and want help thinking through adoption from the start, that's part of how we work on every project, and it's worth raising on a scoping call before the build begins, not after.
ACAS publishes general guidance on managing organisational change that covers the wider people-management side of a rollout well beyond the software itself.
✦ Where this fits
More on this from us: how we work.