CRM Tools Don't Break. Their Integrations Do.

A client once told me their HubSpot was “broken.”

Leads were disappearing. Reports didn't match. Sales said marketing was sending garbage; marketing said sales wasn't following up. They'd already hired two agencies and migrated to HubSpot from a previous CRM, thinking the tool was the problem.

I spent a week tracing what actually happened to a single lead.

Here's what I found: a user filled out a form. GA4 tracked it. The form submission fired a webhook to Zapier, which wrote to HubSpot. But the webhook was also hitting WebEngage directly with a different user ID. Meanwhile, the sales team was manually exporting from HubSpot into a Google Sheet because the HubSpot reports didn't show the data they wanted. WhatsApp replies came through a separate tool that never talked to HubSpot. And the ad platforms were pushing conversions back to GA4 but not to the CRM.

The CRM wasn't broken. The CRM was working perfectly.

Five systems disagreed about what a lead was. That's the real story.

The diagnosis pattern

After enough of these, I learned the pattern. When someone says “the CRM is broken,” they usually mean one of these things:

• Data disagreement — Multiple sources of truth for the same entity. The lead exists in HubSpot, but also in the Zoom registration list, also in the WhatsApp tool, also in a marketer's Airtable. Each has different fields. Nobody knows which is right.
• Event leakage — Events fire correctly in one system and get lost on the way to another. GA4 tracks a conversion, but the CRM never sees it because the webhook failed silently three weeks ago.
• Taxonomy drift — UTM parameters are inconsistent across campaigns. “meta_ads” in one, “Facebook Ads” in another, “fbads” in a third. Same source, three different dashboard rows.
• Identity fragmentation — The same user has five different IDs across five systems. There's no key that joins them. Attribution is impossible.
• Workflow assumption — An automation built six months ago assumes a state that no longer exists. The owner left. Nobody remembers why it fires.

Every single one of these is an integration problem. Not a tool problem.

Why clients keep buying new CRMs

The pitch is compelling: “Our current CRM is a mess. Let's switch to [better CRM].”

Three months later, the new CRM is also a mess. Sometimes worse, because you've now got legacy data in two places and half the integrations weren't ported.

I've watched this happen four times. The pattern is so consistent I can predict the timeline. Migration takes longer than estimated. Half the automations don't come across cleanly. The new CRM has different object models so your reports need rebuilding. Six months in, your team is frustrated again — and now the blame has moved to the new vendor.

The CRM was never the problem. The *spaces between* the systems were the problem.

What actually works

When I rebuilt the MarTech stack at a $30M ARR ed-tech, we didn't migrate CRMs. We fixed the integrations. Here's what that looked like:

Step 1: Draw the map. Every system. Every data flow between them. Every webhook, every manual export, every automation. This takes a full day and looks terrifying when you're done. Good. That's the actual system.

Step 2: Pick a source of truth for each entity. The lead lives in the CRM. The event data lives in PostgreSQL. The user session lives in GA4. Pick one system per entity and enforce it. Anything that writes to a different system for that entity gets rewired or killed.

Step 3: Enforce a single taxonomy. UTM parameters, event names, field names — one spec, enforced at the edges. Link builders with validation. Event tracking wrapped in a schema. Tools like Segment or a custom n8n layer can normalize inputs before they hit the CRM.

Step 4: Monitor the handoffs, not the tools. The CRM will tell you it's healthy. GA4 will tell you it's healthy. Each tool passes its own health checks. What you need to monitor is the *seams* — the places where data moves from one system to another. Log every handoff. Alert on silent failures.

Step 5: Make the broken integrations visible. The most insidious failures are the ones nobody sees. A webhook that's been failing 10% of the time for six months. A Zapier zap that broke when an API changed. Dashboards that silently drop rows. If you can't see failures, you'll accept them.

The harder truth

Fixing integrations is unsexy work. It doesn't get PRs. It doesn't get launch announcements. It doesn't come with a vendor demo and a champagne toast. It's just: sit with the system, trace every data flow, find the leaks, plug them.

But it's what actually moves the numbers.

At that ed-tech, we didn't change any CRM. We didn't buy any new tool. We just fixed the seams. Lead quality went up 20%. Churn went down 30%. Reports started matching reality. The sales team stopped blaming marketing. Marketing stopped blaming sales. Because the data finally agreed.

If you're reading this as a buyer

Before you migrate your CRM, do this:

1. Ask your team: “Where do we disagree about the data?” Write down every answer. 2. For each disagreement, find the two systems that disagree. Trace the path between them. 3. You'll find the real problem in about 80% of cases. It won't be the CRM.

The other 20% of the time, the CRM really is the problem. Usually because you outgrew it — your object model is now more complex than the tool supports. That's a real migration case.

But the first 80% don't need a new tool. They need someone who will sit with the system, trace every integration, and fix the seams.

That's most of what I do. The tool isn't broken. The integrations are.