QubicQubıc
Operational excellence and team enablement

Why half the team doesn't use the new tool — and how to prevent it before investing.

Qubic · Insights · 7 min read

A sleek black laptop on a white desk in a minimalist setup with natural lighting.

Typical scenario: leadership decides on a new tool, six months later half the team is still working the old way. The reason almost never is the tool — the reason is how the people were prepared for it.

A typical scenario in companies: leadership makes a decision about introducing a new tool — CRM, ERP, project system, AI assistant — a significant sum has been invested in licenses and implementation. Six months later, half the team is still working the old way, using Excel or the old system. The investment partially fails, frustration grows, and no one is sure whose fault it is.

I've seen this scenario in a dozen companies. And almost always the reason wasn't the tool — it was how the people were prepared for the tool.

Three real reasons adoption fails

Reason 1: People aren't included in the decision

The most common mistake: leadership decides on a new system based on a demo presentation or a consultant's recommendation. The people who will use that system find out when the contract is already signed.

The consequence is predictable. A team that wasn't included in the decision has no stake in the tool's success. If the tool works awkwardly, it's easier to go back to the old way than to help with adoption.

Contrast: a company that, before the decision, involves 3-4 key team members in testing options. Those people become internal „ambassadors" — when the tool arrives, they already understand it, see the value, and help others. Adoption goes faster because there's an internal alliance.

Reason 2: Training is a lecture, not practice

Typical training about a new tool looks like this: a lecturer from the vendor spends half a day demonstrating functionality, showing slides, giving an overview. The team sits, nods, looks at their phones.

A week later, no one remembers what they heard. The reason: training wasn't tied to concrete problems the team works on every day.

Training that works looks different: it takes a real client who's currently problematic, a real process that's currently being done poorly, and walks through how that would look in the new tool. The team isn't learning about „features," they're solving their concrete problems.

The difference in result is enormous. A lecture is forgotten. Hands-on work stays.

Reason 3: No support after the first weeks

After training, people return to their workstations and try to apply the new tool to real situations. Questions appear — „what would this look like for this client," „what if the client doesn't have this piece of data," „how does this integrate with that other system."

If at that moment there's no one to ask, people go back to the old way. Excel works because they know it. The new system doesn't work for their specific case because they don't understand it well enough.

Companies that successfully introduce new tools have structured support for the first 6-8 weeks — someone available for questions, regular reviews where problems that have appeared get solved, tool adjustments based on real usage.

That's the phase most often skipped, because vendors typically sell „implementation and training," not „post-launch support." But that's the phase where success or failure is decided.

How to prepare the team before you invest

The biggest lever is involvement before the decision. That sounds obvious but it's rarely done systematically.

Practical approach for companies of different sizes:

  • Identify 3-4 key team members who will use the new system most. Ideally people who understand current problems — not necessarily the most technical, but those who have a clear picture of where the current way doesn't work.
  • Include them in option assessment. Give them the chance to test 2-3 serious candidates, on real data or processes, over a few weeks. Not demo presentations — actual usage.
  • Ask for their recommendation. Not the final decision — that stays with leadership — but an argument for why one tool would be better than another for their actual work.
  • When implementation starts, they become internal ambassadors. They help colleagues, know „how we do it here" in the new tool, can adapt training specifically to your context.

This adds 4-6 weeks to the overall introduction time. In return, adoption is typically 80%+ instead of 50%, which is the difference between an investment that pays off and one that partially fails.

What to do if you've already invested and adoption isn't working

If you're already in a situation where the system is implemented but half the team doesn't use it — you aren't alone, and it isn't too late.

The biggest mistake at that moment is forcing it. „Everyone has to use the new system, end of story." That creates resistance and frustration, and people find ways to work around it.

The approach that works: find out why it isn't being used. Individual conversations with those who don't use the system, questions like „what isn't working for you," „where is it slow," „what would you change."

Often it turns out there's a concrete, solvable problem — some functionality from the old system is missing, the system is slower for their specific type of work, integration with another tool isn't working. When that's solved, adoption follows.

If the problem isn't solvable in the short term, it's worth considering parallel work — some people work the old way, some the new way, and the decision is based on real usage. That's not ideal, but better than a situation where half the team is sabotaging a system that was imposed on them.

Conclusion

Technology is 20% of adoption. People are 80%. Companies that understand this spend more time preparing the team and less time on tool selection, and they get much better results than those that do it the other way around.

The biggest lever is involving the team before the decision is made. The second is training through concrete problems. The third is structured support for the first weeks. All three are predictable — and all three are most often skipped.

If you're considering introducing a new tool or AI system, or you're struggling with adoption of something already invested in, take a look at our Training and adaptation service — we work with your team before, during, and after introduction, so the investment actually pays off.