I've been managing tech projects for twelve years now. I've helped teams migrate between CRMs, set up automation workflows, and integrate systems that weren't meant to talk to each other. And I've watched the same mistake happen over and over.

Someone decides the current system isn't working. Maybe deals are slipping through the cracks. Maybe customer data lives in three different places. Maybe reports take two days to compile when they should take ten minutes.

The instinct is to find a better tool. The team researches options, sits through demos, compares pricing tiers. They pick something that looks promising. HubSpot instead of Keap. GoHighLevel instead of Ontraport. A custom WordPress setup instead of the existing system.

Then six months later, they're having the same problems.

The real issue is almost never the tool

Last year I worked with a consulting firm that wanted to switch from Keap to HubSpot. They were convinced Keap was too limited. The sales team wasn't updating contact records. Follow up emails were inconsistent. Pipeline reports were useless.

Before we started the migration, I asked them to map out their actual process. Not what the process should be. What actually happens when a lead comes in.

Turns out the sales team didn't update Keap because they were also logging everything in a shared Google Sheet. Why? Because two years ago, one manager wanted specific fields that nobody bothered to add to Keap. So they built a workaround. That workaround became the habit.

The follow up emails were inconsistent because three different people had created automation sequences that overlapped. Nobody documented which sequence did what. The pipeline reports were useless because half the team used custom deal stages that didn't match the official stages.

None of this had anything to do with Keap's capabilities. Moving to HubSpot would've just been expensive chaos.

Map the information flow before you change anything

Here's what I do now before any major tool change or integration:

  • Sit with each team that touches the system and watch them work for at least two hours
  • Ask where they get information and where they put it when they're done
  • Find every spreadsheet, Slack channel, email folder and sticky note system that exists alongside the official tool
  • Document who's responsible for each handoff between teams
  • Look for places where someone manually copies data from one place to another

This takes time. For a team of fifteen people, it usually takes me a full week. But it's the only way to see what's actually broken.

Sometimes the tool really is the problem. I worked with a team last year where Ontraport's API rate limits were causing real issues. They were hitting the limit every afternoon, which delayed their automated reporting by hours. That was a legitimate technical constraint. We moved them to HubSpot and the problem went away.

But that's maybe one project in five. The other four are process problems disguised as tool problems.

What didn't work

Early in my career, I tried to fix process issues by just building better documentation. Write down the correct process, share it with the team, problem solved.

That never worked. People don't follow documentation when the documented process is slower or more awkward than their workaround. You have to fix the underlying friction first, then document what actually makes sense.

The practical bit

Next time someone on your team says you need a new tool, don't start shopping. Spend a week mapping how information actually moves through your organization right now. Find the workarounds. Find the manual steps. Find the duplicated data entry.

Half the time, you'll realize you can fix the problem with what you already have. The other half, you'll at least know exactly what the new tool needs to do.