Key takeaways
- Software adoption is the point where a team does its work in the new system by default, which usually comes well after the day the logins start working.
- When a new system falls apart after it is handed over, the main cause is usually change management: no rollout plan, too little training, or no buy-in inside the team.
- In a small business the owner or manager is the change program. A digital adoption platform is built for large companies running dozens of apps.
- Adoption can be checked without analytics: new records appear in the system every day, the old spreadsheet stops changing, and questions arrive in the shared channel.
Search for software adoption and most of page one is written by companies that sell digital adoption platforms, for organizations large enough to have a training department and hundreds of apps. Their advice is sound for that world. A 20-person service firm that just had a system built for it is in a different one: there is no IT team, the people who need training are also the people serving clients, and the old Google Sheet or Excel file is still one click away.
We build operating systems for service businesses, on Airtable and Softr with automation through Make and n8n, and we have watched systems take hold and watched others decay after launch. This guide is about the difference.
What is software adoption?
Software adoption is the point where the people a system was built for do their work in it by default, without being reminded. It is measured in behaviour: records are entered where they should be, decisions are made from the system’s numbers, and the old tools stop being used. A system can be live for months without being adopted.
The research on how new tools spread is old and well known. Everett Rogers’ diffusion of innovations describes the curve from early adopters to laggards, and most adoption guides reuse it. In a small team the curve is shorter and more personal: it might be four people, and one of them may have run the business from a spreadsheet for years.
Why do new systems fail to get adopted?
New systems fail to get adopted mainly because nobody managed the change. The system was built and handed over, but there was no plan for rolling it out, the training covered the buttons and skipped the reasons, and the team never agreed it was better than what they had. The old way stays available, so people drift back to it.
Ask us why some clients keep a system running on their own while others let it fall apart, and our answer is change management. It is critical whenever a business brings in new processes and new technology at the same time. When we hand over the keys to a new system, the client needs a plan in place for putting it to work.
Smaller causes show up again and again:
- The old tool is never retired. If the spreadsheet still works, someone keeps using it, and now the data lives in two places.
- The first problem has nowhere to go. A person gets stuck, finds no quick answer, and quietly goes back to the old way instead of asking.
- The system does not match the real process. It was built from the official version of how work runs, and the team has to work around it every day. Mapping the process with the people who do it prevents most of this.
What is change management for new software?
Change management for new software is the plan for moving people from the old way of working to the new system: who needs to know what, in what order, how they get trained, and what happens to the old tools. It is the human side of a rollout, usually led by the owner or a manager.
The best-known frameworks were built for large organizations. Prosci’s ADKAR model breaks change into awareness, desire, knowledge, ability and reinforcement, and the general field is summarised in Wikipedia’s change management entry. The five letters translate well to a small team. People need to know why the change is happening, want it, learn how to use the system, be able to do their real work in it, and be kept on it until it is habit.
Our part is to recommend how the rollout should go and to run the training as part of the change. What we cannot supply is the buy-in. That has to come from the client’s side.
How do you roll out a new system in a small business?
Roll out a new system by involving the team before launch, training each role on its own work, switching on a fixed date, retiring the old tools, and keeping a quick channel open for questions afterwards. The goal is to make the new system the only sensible place to do the work, as early as the team can manage it.
In practice that means:
- Involve the people who will use it while it is being built. On our projects the client’s key team members sit in a shared Slack channel with us during the build, and the edge cases and missing logic come out there, before launch rather than after.
- Train by role, on the real work. A coordinator needs to update a record and see what is due today. A manager needs the reports. Neither needs a tour of every screen.
- Explain the reasons as well as the steps. People adopt a tool when they can see how it helps their own day, and when they understand why each step exists.
- Pick a switch-over date and retire the old tool. Make the old Google Sheet or Excel file read-only, or archive it. Two live systems is one of the most common ways adoption fails.
- Check the moved data together. If the client list or open jobs came over from the old tool, have the people who know them confirm they are right. One wrong record early on costs a lot of trust.
- Keep the question channel open. The first time someone gets stuck decides how they feel about the system. A fast answer keeps them in it.
How do you know if a new system is being adopted?
You know a new system is being adopted when the work shows up in it without anyone chasing it. In a small business you do not need an analytics tool to see this. Look for new records being created every day, reports being pulled from the system rather than rebuilt by hand, and the old spreadsheet going quiet.
| Signal | Adopted | Not adopted |
|---|---|---|
| New records | Created in the system as the work happens | Entered in batches, or by one person on behalf of others |
| The old spreadsheet | Archived or no longer edited | Still updated “just in case” |
| Reports | Pulled from the system when needed | Rebuilt by hand before meetings |
| Questions | Asked in the channel, often early on | Rare, because people have stopped trying |
| Status | Visible to everyone in the system | Still asked for in person or by email |
Questions are a good sign. A team that asks a lot early on is a team using the system.
What is the best digital adoption platform?
For large organizations, the best-known digital adoption platforms include WalkMe, Whatfix and Userpilot, which add guided tours, tips and usage analytics on top of other software. For a small business adopting one system built for it, the usual answer is none of them. Adoption is better designed into the system itself than added later as a layer.
Designing it in looks like this on real projects:
- Views built for each role. At Affinity Care, every role got dashboards and filtered views in Airtable that show exactly what it needs, and none of them requires technical knowledge to use or maintain. Coordinators update a record in seconds, and leadership sees compliance status live.
- Control without effort. Nomads Cast wanted onboarding to be fully automated and fully under their control. A control panel where an operator can switch a single client’s onboarding on or off gave the team the confidence to hand the process to the system.
- Training on the logic. At Scenthound, we trained the staff on how the new system works and the reasoning behind it. Adoption was fast because the team understood the system rather than memorizing where to click.
We do not sell an adoption platform, so we have no reason to talk anyone out of one. A firm with dozens of tools and hundreds of staff may well need one. A firm of 20 with one new system needs a good rollout.
Who is responsible for adoption, the client or the builder?
Both, for different parts. The builder is responsible for a system that fits the real work, for documentation, for training and for being reachable when something breaks. The client is responsible for buy-in: deciding the new system is how work gets done, retiring the old tools, and holding the team to it. Neither side can do the other’s part.
The handover is where the two meet. What a system handover should include covers the builder’s side in detail, from ownership of the accounts to the documentation of what runs automatically.
Frequently asked questions
What is the difference between technology adoption and adaptation?
Adoption is a team taking up a new tool and using it for its work. Adaptation is changing something so the two fit, either the tool to match how the team works or the team’s process to match the tool. Most successful rollouts involve some of each, and a custom-built system leans toward adapting the tool.
Should we run the old and new systems in parallel?
Only briefly, and only to check that the data moved correctly. A long overlap means every update has to be made twice, and people choose the system they trust more, which is usually the old one. Set the date the old tool becomes read-only before the rollout starts.
Why do employees resist new software?
Usually because they cannot yet see what it does for their own day, and because switching costs them time while they are still serving clients. Resistance drops when the training covers their real tasks, the reasons are explained, and someone answers their questions quickly at the start.
Change management and training are part of how we plan every operations consulting engagement.