Getting your team to actually use the new system

There's a specific kind of quiet that follows a failed automation project. The system runs. The dashboards are green. And three weeks later somebody is still keeping the real numbers in a spreadsheet, because the new thing takes four clicks where the old thing took one, and nobody who chose it does the job every day.

This is the most common way automation money gets wasted, and it is almost never a software problem. It's a problem of having solved for the person who signs the invoice rather than the person using the thing at 4:40 on a Friday.

What actually predicts adoption

You don't have to guess at this. Information-systems researchers have measured technology adoption in real organizations since the 1980s, and the findings are unusually stable.

Fred Davis's Technology Acceptance Model, published in MIS Quarterly in 1989, reduced acceptance to two perceptions: whether someone believes a system will improve their job performance, and how much effort they think using it will take. Fourteen years later, Venkatesh, Morris, Davis and Davis consolidated eight competing models into the Unified Theory of Acceptance and Use of Technology, which explained roughly 69% of the variance in people's intention to use a system — a very high figure for behavioral research — using four determinants.

Performance expectancy was the strongest predictor in that work, which carries a blunt implication: if you can only fix one thing, fix whether the tool visibly makes the user's own day shorter. Polish is secondary.

The trade nobody puts in writing

Most automation moves effort rather than eliminating it. A report the manager used to assemble now assembles itself — but only if three people tag records correctly all week. That's often a good trade for the business and a bad one for the individual doing the tagging, and pretending otherwise is why the tagging stops in month two.

Say it out loud instead. "This adds about a minute per record for you, and it removes four hours a month from the close." Then either take something else off that person's plate, or accept that compliance will decay and build a check for it. What doesn't work is describing a system as a pure win to the one person for whom it isn't.

Where rollouts go wrong

Kotter's 1995 Harvard Business Review essay on why transformation efforts fail was written about corporate restructuring, but three of his eight errors map directly onto a twelve-person company installing a new CRM.

Undercommunicating the vision by a factor of ten. One kickoff email is not communication. If people can't say in a sentence what the system is for, they fill the gap with the most cynical available explanation — usually surveillance.

Not removing obstacles. If the new process needs an approval only one person can give and that person is on the road, the process dies and everyone reverts. Obstacles are usually mundane and specific.

Declaring victory too soon. Go-live starts the adoption period; it doesn't end the project. The first month is where you find out what the process map missed — the case for mapping it properly first.

A rollout sequence that tends to hold

None of this is complicated. It's mostly a matter of doing things in an order that gives you information before you're committed.

1. Map the real process, including the exceptions. Not the described process. This is where you learn which steps exist only because someone left in 2019.
2. Pick one person and one workflow. Not one department. One person, one thing they do daily, where you can watch them do it.
3. Choose a skeptic. The enthusiast routes around any flaw and reports success. The skeptic tells you the fourth click is the problem — the only useful information available at that stage.
4. Run both systems for two weeks. Parallel running is unglamorous, and it's how you find out whether the automation handles the messy cases.
5. Fix the friction before you widen the group. Every unfixed annoyance multiplies by headcount.
6. Name a human owner for 60 days. Not "IT." A person, with a name, whose job it is to be interrupted about this.
7. Retire the old path deliberately — but not until the new one handles what the spreadsheet was handling.

Steps two through four hold most of the value, and they're the ones compressed out of the plan when someone wants to be live by quarter end.

When not to push adoption

Sometimes the resistance is correct and the honest move is to stop. If the same three people independently work around the system in the same place, that is not a training gap — it's a design defect they diagnosed for you for free. If the process changes every few months, automating it locks in a shape that will be wrong by spring. And if the volume is genuinely low, the payback may never arrive: workflow automation: what to automate first covers how to check that before you spend.

The most expensive automation projects aren't the ones that get rejected. They're the ones that get half-adopted, where two people use the system, three keep the spreadsheet, and the reporting is now drawn from both.

Frequently asked questions

Why do employees resist new automation systems?

Resistance is usually rational rather than emotional. Technology-acceptance research consistently finds that people adopt systems they believe will improve their own job performance and abandon ones that add effort without visible return. When a new system moves work onto a front-line person so a manager gets a cleaner report, that person isn't being difficult by resisting — they are correctly reading a trade made without them. Other common causes: unaddressed fears about job security, a system designed around the buyer's needs rather than the user's, and no clear person to ask when something breaks.

How long does it take for a team to adopt a new automation tool?

For a single workflow in a small business, expect meaningful adoption in four to eight weeks and treat anything faster as a sign you have not yet found the exception cases. The first two weeks typically run in parallel with the old process, which surfaces the situations the design missed. Weeks three through six are where friction gets fixed and usage either takes hold or decays. Full adoption is not reached until the old path is deliberately retired, and that should not happen until the new one demonstrably handles what the old one did.

Should we train everyone at once or roll out gradually?

Gradually, in almost every case. Training everyone at once means discovering a design flaw across your entire team simultaneously, and first impressions of a broken tool are extremely durable. Starting with one person on one workflow lets you find the friction while the cost of fixing it is one conversation rather than a company-wide re-announcement. The exception is a system where partial adoption creates worse data than no adoption — a shared calendar or a CRM that only half the team updates. There, run a short pilot, then switch everyone on the same day.

Who should own automation adoption in a small business?

A named individual who uses the system themselves — not a committee, and not an outside vendor. That owner's job for the first sixty days is to be interruptible: to answer "why won't it let me do X" within the hour, and to keep a running list of every friction point reported. The list is the roadmap. Executive sponsorship matters for removing obstacles like approvals and access, but day-to-day ownership has to sit with someone close enough to the work to tell a complaint from a real defect.

Is the statistic that 70% of change initiatives fail accurate?

No. The figure circulates widely and is usually attributed to McKinsey or John Kotter, but neither published it as a measured result. Mark Hughes examined the most-cited sources for the claim in the Journal of Change Management in 2011 and found no valid and reliable empirical evidence for it. Change initiatives do fail, and often, but no credible measurement of a 70% rate exists. Treat its appearance in a vendor pitch as a signal about that vendor's sourcing standards rather than as information about your odds.

What is the difference between change management and training?

Training teaches people how to operate a system. Change management addresses whether they will choose to. The two are frequently confused, which is why so many rollouts respond to low usage by scheduling another training session — a reasonable move if the problem is capability, and a wasted one if the problem is that the tool adds work. Before booking more training, watch someone use the system and count the steps against the old way. If the new path is longer, no amount of instruction will fix it, because the people avoiding it already know how it works.