Back to blog
    • Adopción de herramientas
    • Equipos
    • Gestión del cambio
    • Productividad
    • Dirección

    How to roll out a new tool without your team hating it

    The tool is almost never the problem. The problem is how it's introduced. This is what I've seen work, and fail, in companies of 5 to 50 people.

    8 min
    Equipo de trabajo reunido alrededor de una mesa aprendiendo una herramienta nueva

    The scene that keeps repeating

    Management buys a new CRM, a management system or an AI tool. The license gets paid, a two-hour training happens, an email goes out saying "from Monday everything goes through here". Three weeks later, half the team is still on their spreadsheet, the other half uses the tool halfway, and the data lives in two places. Worse than before.

    I've seen this pattern in distribution companies in Valencia, clinics in Lyon and firms in Miami. It's not a country problem or an industry problem. It's a method problem.

    And it has a solution. But first you need to understand why people resist.

    Why people reject new tools (and they're right)

    When an employee doesn't adopt a tool, it's almost never laziness. It's usually one of these reasons, all of them legitimate:

    It adds work without removing any. Now they have to fill in the CRM on top of what they already did. Nobody took away the spreadsheet or the weekly report.

    They don't understand what it's for. They were told "you have to use it", not "this means you stop chasing invoices by hand".

    They're afraid of looking bad. They don't know how to use it, don't want to ask, and prefer to stick with what they master.

    They suspect it's there to monitor them. A CRM that logs every call sounds like surveillance if nobody explains otherwise.

    It's happened before. It's the third tool in two years. The previous two were abandoned. Why would this one be different?

    If you recognize any of these, it's not your team's fault. Nobody designed the adoption. Only the purchase was designed.

    The method that works: seven steps

    1. Start with the pain, not the tool

    Before announcing anything, talk to the people who will use it. Ask what wastes their time, what frustrates them, what they'd do differently. Write down their exact words.

    Then, when you present the tool, use those words: "María told me she loses an hour a day looking up order status. With this, she sees it in one click." That's very different from "we're implementing an ERP to improve operational efficiency".

    2. Remove before you add

    For every new task the tool introduces, eliminate an old one. And say it explicitly: "From now on the tracking spreadsheet and the Friday report are gone. The system generates that on its own."

    If you can't remove anything, rethink the tool. A tool that only adds work doesn't survive.

    3. Pick two people, not the whole team

    Find the two most curious people, or the two most fed up with the current problem. They test the tool two weeks before anyone else, with direct access to you or to whoever is implementing it, so questions get answered on the spot.

    When the rest of the team gets it, those two are already in-house experts. And a colleague saying "this saved me half an hour a day" convinces more than any executive.

    4. Train with real cases, not demos

    None of "this is how you create a generic contact". Better: "Take the last customer that came in yesterday. Let's enter it together right now." Training with your own data sticks. Training with sample data is forgotten in 48 hours.

    And keep it short. Three 30-minute sessions a week apart work far better than one full day.

    5. Run both systems in parallel for a limited time

    Cutting over abruptly creates panic. Leaving it open forever creates two versions of the truth. The answer: two or three weeks in parallel with a clear end date communicated from the start. "On the 15th the spreadsheet gets archived. Until then, if something doesn't work in the new system, tell me and we fix it."

    6. Answer questions in hours, not weeks

    During the first month, every unanswered question is a reason to go back to the old way. Have a channel (a WhatsApp group, an internal chat) where questions get resolved the same day. This is one of the reasons the monthly partnership includes direct support for the team: adoption is decided in those first weeks.

    7. Show the result at four weeks

    After a month, show the numbers: hours saved, errors avoided, quotes closed faster. And thank the people who pulled the cart, publicly. People repeat what gets recognized.

    Practical rule: if a month after rolling out a tool you can't point to a concrete task that has disappeared from someone's day, adoption is going to fail. Fix it before it's too late.

    Three mistakes I see constantly

    Choosing the tool for what it does, not for what your team needs. A CRM with 200 features is worse than one with 15 if the 15 are the ones you use. Complexity kills adoption.

    Training once and assuming it's done. Training is a process, not an event. Initial session, refresher a week later, review after a month, and open questions always.

    Not using the tool from the top. If the boss keeps asking for the report by email instead of looking at the dashboard, the team understands the tool doesn't matter. Lead by example or don't lead.

    A concrete case

    A distribution company with 18 people had two failed CRM attempts behind it. The third time we did this: talked to the four salespeople, pulled out their top three complaints (not knowing which quotes were pending, wasting time on the spreadsheet, not having data on their phones), and configured the system to solve only that. Nothing else.

    Two salespeople tested it for two weeks. We retired the spreadsheet with a fixed date. A 30-minute training with their own customers. A WhatsApp group for questions.

    After a month, 100 percent of the team was using it. Not because they were different people than in the two previous attempts, but because this time the tool took work away instead of adding it. And because someone was there to answer when something didn't work.

    Before your next tool

    Ask yourself three questions:

    1. Which concrete task will disappear for each person who uses it?
    2. Who will answer questions in the first month, and how fast?
    3. What date does the old system get shut down?

    If you don't have all three answers, don't buy yet.

    And if you'd like help choosing and rolling out the next tool with this method, book a call. In 15 minutes I'll tell you whether the one you have in mind fits your team or whether there's a better option.

    Carlos Canelón

    Written by

    Carlos Canelón

    Technology partner for business owners

    Twenty years building software for companies. I help owners and executives save time and sell more with automation, AI and custom systems. Working with clients in Spain, France, the United States and Venezuela.

    Share this article

    Contact me on WhatsApp