Your HubSpot is live. But that's not where growth begins.

Your HubSpot is live. But that's not where growth begins.

Configuring HubSpot is a technical project. Getting it to actually work for your team is something else: adoption. Roughly 70% of large CRM programmes miss their goals, and less than 10% of those failures come from the technology. Below you'll find why implementations stall, how to make adoption measurable, and the five-cluster framework that addresses the real drivers: People, Process, Data Quality, Technology and Product Usage.

The implementation is finished. The system is live. Dashboards are built. And yet: the pipeline isn't accelerating, the team half-works in HubSpot and half in Excel, and the "single source of truth" is anything but.

Familiar? Almost certainly. And that's the point of this piece. The reflex when a CRM programme stalls is nearly always to add more tech, more configuration, more features. But in the vast majority of cases, that's not where the problem lives. It lives in adoption -  and adoption is a different discipline from implementation.

THE PROBLEM

WHY DO SO MANY HUBSPOT IMPLEMENTATIONS STALL?

There's one number every CRM leader should know: roughly 70% of large CRM and change programmes miss their goals. That's not a headline from one study. It's the convergence of several. McKinsey sees 70% across change programmes broadly. CSO Insights measures up to 70% specifically for CRM adoption. Forrester lands around 47–49% for CRM projects, with change management as the dominant cause. The Standish Group finds only around 30% of IT projects fully succeed. Different angles, different definitions, the same order of magnitude.

The surprise, though, isn't the number. It's the cause distribution. Of all these failures, about 60% or more is people-related, roughly 30% process-related, and only 6 to 10% is technical. The tool is almost never the problem. Yet the average organisation still puts around 80% of its energy into tech configuration and only 20% into adoption and process. Precisely the wrong half.

That's why implementations that succeed on paper stall in practice. HubSpot does what you configure it to do. But whether the team uses it, whether they trust the data, whether leadership steers on it -  that's a separate question, and it structurally gets too little attention.

ASSUMPTION VS. FACT

IS THIS A TECH PROBLEM, OR SOMETHING ELSE?

Four assumptions that fall apart the moment you look at the data.

Assumption: "It's the tool." In less than 10% of cases is technology the actual issue. HubSpot does what you tell it to do. The question isn't what the tool can do -  it's whether your team actually uses it.

Assumption: "More configuration will fix it." More fields, more required steps and more automation only accelerate what's already there. If the underlying process isn't clear, your system just accelerates the confusion.

Assumption: "Failure means the system gets thrown out." Rarely. Much more often, the system keeps running but underused. Reps fill in the minimum, marketing keeps the real lists in Excel, service works outside tickets. The single source of truth silently gets demoted to a half-truth.

Assumption: "If it goes live, adoption follows." Adoption is not a by-product of go-live. It's a discipline that begins there, and the first 90 days determine whether the system compounds with the organisation or slowly erodes.

Fact: this is not a software problem. It's an adoption problem. That's the reframe the entire question hinges on. As long as you treat adoption as a checkbox after go-live, you'll keep getting the same pattern with every new system you roll out.

THE DEFINITION

WHAT IS HUBSPOT ADOPTION, EXACTLY?

Adoption isn't "our people log in." Adoption is: HubSpot is used as intended, across multiple roles, with trust in the data, with ownership of the usage, and with deepening over time. If any one of those four is missing, you're really talking about logins -  not adoption.

That's also what makes adoption fundamentally different from implementation. Implementation ends at a moment: go-live. Adoption doesn't end, it compounds. It starts the first time a user opens the system and it stops when the last user falls back to a workaround. Because it has no end point, you can't wrap it as a project deliverable. Adoption is an operational capability, not a milestone.

THE FRAMEWORK

ADOPTION IN FIVE CLUSTERS.

The classic adoption lens works with three buckets: People, Process, Technology. In HubSpot practice, we consistently see that two of those buckets fail so often they deserve their own cluster: data quality and product usage. What follows is the layered version, with a core question, failure modes, success factors and the signal to measure for each cluster.

CLUSTER 1

PEOPLE -  WILL AND OWNERSHIP.

Core question: does the team want and know how to work with it, and who owns adoption?

Failure modes: the sales team wasn't involved in the choice; HubSpot feels like control instead of a tool; there are no internal champions; leadership doesn't use it themselves; after go-live, no one owns adoption.

Success factors: visible ownership from leadership (who use the system themselves), users involved from day one in the configuration, role-specific value (sales: less admin, more selling; marketing: seeing which campaigns drive revenue; service: faster resolution with full history), and a champion network per team continuously gathering feedback.

Signal: percentage of daily active users, and whether Excel workarounds actually disappear.

CLUSTER 2

PROCESS -  WORKFLOWS BEFORE AUTOMATION.

Core question: are the workflows right and standardised before we automate them?

Failure modes: automation rolled out on a process that was never defined; qualification criteria differ by team; the same sales process runs in five flavours. The system accelerates the confusion.

Success factors: current state mapped first, target state explicitly designed, standardisation before automation, and clear governance over who guards which rule.

Signal: lead response time, and whether deals stall in the same stage repeatedly.

CLUSTER 3

DATA QUALITY -  TRUST AND CLEANLINESS.

Core question: does the team trust the data, and does it stay clean?

Failure modes: dirty legacy data gets migrated over, making the system feel unreliable from day one. Fields no one fills. Duplicates. A pipeline no one dares steer on because "those numbers aren't right anyway."

Success factors: clean before migration (or, where necessary, a clean start), validation rules against decay, and data stewardship with a clear owner per object type.

Signal: percentage of required fields filled (aim for 90%), duplicate ratio, and record completeness over time.

CLUSTER 4

TECHNOLOGY -  FIT WITH THE REAL WORK.

Core question: does the configuration fit the real work, or does the human have to adapt to the tool?

Failure modes: overloaded with features nobody uses; configured for how you want people to work instead of how they actually work; missing integrations that leave critical context outside HubSpot; a migration that stalls halfway.

Success factors: right-sized build (what you need now, with a roadmap for later), user-centered configuration, thoughtful integration architecture (email, calendar, marketing automation, ERP), and role-specific setup.

Signal: number of unused features, and integration coverage.

CLUSTER 5

PRODUCT USAGE -  DEPTH OVER TIME.

Core question: is HubSpot actually used as intended, and does that use deepen?

Product usage isn't a separate island. It's the outcome of the other four clusters combined. Only once People, Process, Data Quality and Technology are in place can usage deepen from "I log in" to "I work in it" to "I steer on it."

Failure modes: shallow use, features that don't land, drop-off after the first weeks, and new hires learning bad habits from colleagues -  the generational erosion that eventually breaks every stagnating system.

Success factors: measure adoption across three layers (usage data, data quality, business impact), a 90-day adoption check after go-live, active steering on feature adoption, and an explicit Drive phase with training, bugfixing and small optimisations.

Leading signal: daily active users toward 80%, data completeness toward 90%, feature adoption above 60%. Lagging signal: shorter lead response, shorter sales cycle, higher retention, more revenue per rep.

WEIGHTING

WHY FIVE CLUSTERS, NOT THREE -  AND WHERE THE WEIGHT SITS.

The two added clusters -  data quality and product usage -  are precisely where HubSpot programmes most often break in practice. Giving them their own cluster makes them visible, instead of hiding them under "technology."

And then the weighting. Line up the five clusters and People and Process together carry by far the most weight -  together roughly 90% of the success factors. Technology weighs least. Which is exactly the inverse of where most organisations put their energy.

THE FIFTH D

FROM FOUR TO FIVE D'S: WHY DRIVE MAKES THE DIFFERENCE.

The classic project approach for CRM programmes has four phases: Discovery, Design, Develop, Deliver. It ends at go-live.

We've added a fifth: Drive. The reason is empirical. It's precisely the period right after go-live -  the first 60 to 120 days -  when the user population is most vulnerable. Enthusiasm dips, workarounds sneak back in, small bugs feel large, and without active support the behaviour that makes the system "exist but not work" silently installs itself.

Drive isn't aftercare or hypercare. Drive is a structured phase of training, bugfixing, small optimisations, adoption-dashboard monitoring and champion support. When users start slipping back, you intervene. Only when the leading indicators are stably trending the right way does the operational handover complete.

The difference between a successful and a quietly-failing HubSpot implementation almost always lives in this phase.

THE PATTERN

GROWTH CEILING SIGNALS POINT BACK TO ADOPTION.

Interesting pattern from our work across more than 250 growth systems: the classic growth ceiling signals -  the indicators showing you're hitting a plateau -  trace back at virtually every go-to-market motion to an adoption problem.

Founder-led and no documented sales process? Adoption issue. Sales-led and the pipeline grows but revenue doesn't? Adoption issue in qualification. Marketing-led and traffic climbs but purchases don't? Adoption issue in what happens after the click. Marketing-led sales and sales and marketing aren't aligned? Adoption issue in the shared process. Product-led and activation after signup is low? Adoption issue in onboarding. Partner-led and no visibility on partner pipeline? Adoption issue in the partner workflow.

The conclusion: whatever growth ceiling you're hitting, the answer rarely lies in more tooling. It lies in how your team actually uses the tools you already have.

PROOF FROM PRACTICE

WHAT WE SEE AT GRADIENT CLIENTS.

Two observations from work over the past twelve months. Both anonymised.

Case 1 -  B2B business, international, 800+ dealer doors. Remote sales teams working standalone. No sales tool alongside Teams and BI. HubSpot configured, gone live -  and usage cratered within two months. What we saw when we opened it up: HubSpot had been built on assumptions and wishes, not on the actual workflow of people in the field. No monitoring on colleague connectivity, no usage reporting, unclear ownership after the CCO departed, and no adoption targets. The intervention: new stakeholder ownership, processes reviewed, integration rebuilt around the question "where does this data actually live?", dashboards personalised at management, team and person level, and instruction cards inside deal and visit records. Result over 12 months: from ~30 to ~1,140 store visits per month, 16 active users of whom 15 had email integration and 14 had calendar sync. No new system. But a second go-live, with adoption as the actual project goal.

Case 2 -  B2B business with 130+ sales staff across 13 countries. Complex custom build on an enterprise CRM. IT-heavy: specialists needed for every change. Resistance to change ("we always did it that way and it worked perfectly"), a process that didn't match the real workflow, and management not steering on the data -  which made data entry feel like pointless extra work to the users. The intervention on two fronts: technical (process automation, data enrichment from communication, effective API connections) and process (interviews with key users, instruction cards and chatbots, dashboards that make behaviour visible -  because behaviour, when made visible, self-corrects).

Both cases share one thing: the "system" was there. Adoption wasn't. And the fix wasn't in more tool, but in how people, process and data around it were addressed.

WHAT TO DO

FIVE ACTIONS YOU CAN TAKE THIS MONTH.

Not a full roadmap, but five actions that make the difference for most organisations where HubSpot "technically runs" but doesn't really work:

• Run a 90-day adoption check. Six yes/no questions as self-diagnosis: do people log in daily without a reminder? Have the known Excel workarounds been retired? Is HubSpot mentioned in team meetings? Are managers demonstrably steering on HubSpot data? Are required fields filled at more than 90%? Is there a champion with a cadence per team? Fewer than four yes: adoption issue.
• Measure adoption across three layers. Usage data (daily logins, email/calendar connections), data quality (completeness, duplicates) and business impact (lead response, sales cycle, retention). Without these three layers you're steering on a feeling.
• Define an adoption owner per team. No champion network without responsibilities. One person per team, four hours a week on HubSpot usage, gathering feedback and driving improvements.
• Build an adoption dashboard inside HubSpot itself. Visibility drives behaviour. Show who logs in, who has calendar sync, who uses sequences, who fills deals completely. Share it weekly in the team meeting.
• Plan a 90-day Drive phase post go-live. Not a weekly aftercare slot -  an explicit phase with training cadence, bugfix backlog, dashboard monitoring and champion Q&A. This isn't optional. This is the phase where adoption is made or broken.

THE PRINCIPLE

IT COMES DOWN TO ONE PRINCIPLE.

A new system doesn't solve an old problem. The same organisation that failed with the previous system will fail with the new one if the approach doesn't change.

Choosing a tool isn't the moment growth begins. Growth begins when you treat adoption as a strategic capability -  with ownership, measurability, cadence, and the discipline to hold on past the hypercare window.

Or, in Gradient terms: your growth system isn't your stack. Your growth system is how your team uses your stack.

FREQUENTLY ASKED QUESTIONS ABOUT HUBSPOT ADOPTION

WHY DO 70% OF CRM PROGRAMMES FAIL?

Most CRM programmes don't fail on the technology, but on the people and process side. Across studies (McKinsey, CSO Insights, Forrester, Standish Group), the order of magnitude converges on ~70% of programmes missing their goals. Of those failures, about 60% is people-related, 30% process-related, and only 6–10% technical. The tool is almost never the problem.

WHAT IS HUBSPOT ADOPTION?

HubSpot adoption is the use of HubSpot as intended: across multiple roles, with trust in the data, with ownership of the usage, and with deepening over time. Adoption is more than logging in -  it's the level at which the team actually works in and steers on the system.

WHAT'S THE DIFFERENCE BETWEEN HUBSPOT IMPLEMENTATION AND HUBSPOT ADOPTION?

Implementation is a project with a defined end: go-live. Adoption is an operational capability without an end: how HubSpot is used and deepens after go-live. A successful implementation doesn't guarantee adoption; adoption requires a separate discipline with its own ownership, measurement and cadence.

HOW DO YOU MEASURE HUBSPOT ADOPTION?

Across three layers. Usage data (daily active users, email and calendar integration, sequence usage). Data quality (percentage of required fields filled, duplicate ratio, completeness). Business impact (lead response, sales cycle, retention, revenue per rep). Without all three layers you're steering on signals too shallow to base decisions on.

WHAT IS THE 5D METHOD?

Our project approach for CRM programmes uses five phases: Discovery (understand what's really going on), Design (design the system), Develop (build and configure), Deliver (test, go-live, handover) and Drive (training, bugfixing, small optimisations in the critical 90 days after go-live). The fifth phase is precisely where most programmes quietly fail -  which is why we made it explicit.

WHAT DOES POOR HUBSPOT ADOPTION COST AN ORGANISATION?

Directly: lost efficiency, duplicate work (system plus Excel), longer sales cycles, and lagging lead response. Indirectly and heavier: wrong decisions on unreliable data, sales teams working on gut instead of pipeline, and a growth ceiling that looks like a capacity issue but is really a system-usage issue.

Sources: McKinsey -  Changing change management (2015) · CSO Insights via Polar Strategy -  70% of CRM implementations fail due to low user adoption (2023) · Forrester -  Poor change management kills CRM success (2021) · Standish Group -  CHAOS Report (2015) · Vantage Point -  Why 70% of CRM projects fail and how the people-process-technology framework prevents it (2023) · DMNews -  63% of CRM initiatives fail (2019) · internal Gradient observations.

Gradient is the B2B Growth Architecture firm that helps B2B companies design and build growth instead of leaving it to chance. We architect the commercial system where marketing, sales and service operate as one -  including the way HubSpot isn't just standing, but actually being used.

‍

This blog was written by Cas van der Kuil and Frederique Moor