You're Paying for HubSpot, and Your Team Isn't Using It. Here's Why.

From the September 9th, 2026, edition of How Teams Work

I can confidently say we've helped more organizations adopt HubSpot than most.

Note that I said adopt HubSpot, not just use HubSpot.

Most people think adoption and usage are the same thing. People are logged in, uploading records, setting up workflows.

My co-founder Andrew has a different way of putting it: using the platform is just the baseline. Real adoption is when your organization is actually getting value out of it.

If your team is logging in every day but nobody's actually better off, more efficient, or more informed than before, you haven't adopted the tool. You've just added a login to everyone's routine.

I'd take that a step further. Adoption means using the software to actually run the business, not just having access to it. And it doesn't start with the end user. It starts at the top.

If you're the sales leader and you're not in the tool reviewing pipeline, don't be surprised when your reps treat updating deal records as an afterthought.

I call this inspecting what you expect. If you're not inspecting it, you're not really expecting it.

We've seen adoption fail the same nine ways, over and over. Here they are, in no particular order, because these rarely happen in isolation.

1. No defined process before implementation

This is the big one. Teams get excited to set up a new system before they've agreed on what process that system is supposed to run.

Sometimes there's technically a process. It's just that two people defined it behind closed doors and never got it in front of the rest of the team before rollout. Nobody voted against it. Nobody got to give their feedback.

Here's a test we run constantly: ask ten reps to define the entry and exit criteria for each stage in your sales pipeline. Not what stages exist, but what has to be true for a deal to move from one stage to the next. You'll often get ten different answers. Sometimes wildly different ones.

You can usually see this for yourself in about thirty seconds. Go into your portal and type "lead source" into properties. If you find one clean field, you're in good shape. If you find five or six variations, half of them barely populated, that's not a data problem. That's a process nobody agreed on, showing up as a mess in your system.

That's not a HubSpot problem. That's a decision nobody made. And when nobody agrees on the process, your forecast is only as accurate as whichever rep's mental model happens to be closest to reality.

2. No clearly communicated "why"

People don't resist tools. They resist change without a reason attached to it.

The pattern we see constantly: a leader champions the new system for the first few weeks, then disappears back into their daily routine. Three months later, they're asking why nobody's using it, and it turns out they haven't even logged in themselves.

If your team doesn't understand what's in it for them (not the company), they'll do the minimum to get by. Adoption isn't just about showing people how to use a tool. It's showing them why it was built the way it was and how it will make their lives easier.

3. No real training or enablement

This is where budgets get cut first, and it shows.

Training often gets pushed onto someone internally who already has a full plate and no HubSpot background. The result is half-assed enablement, and it produces exactly the adoption you'd expect from it.

Real enablement means multiple training sessions, Loom walkthroughs, SOP guides, and someone your team can actually go ask when they're stuck. It also means treating go-live as the starting line, not the finish line. That's why we build stabilization time into every project. The most important part of any implementation happens after launch, not during it. It doesn’t matter how well designed your system is. If no one was trained on it, no one will use it.

4. Bad or overcomplicated process

Sometimes the problem isn't a missing process. It's too much process.

This tends to show up as a company scales. A team hits product-market fit, starts growing fast, and their process grows right along with it, usually in the wrong direction. Approvals stack on approvals. Exceptions get bolted onto exceptions. We'll go review the last hundred deals a company closed and find a hundred different ways they got there.

This isn't new. Companies used to do this with spreadsheets long before software entered the picture. You'd walk in, and someone would say, "No, that's not the spreadsheet; it's this other spreadsheet." Same instinct, just a different tool holding the mess.

We've gone looking for a workflow or a property we know a client had built, only to find second and third versions of it sitting in the portal. Turns out the original version wasn't working, someone tried again, and eventually the person who built all of it left the company two years ago. Nobody remembers which version is live. Nobody remembers why the older ones are still turned on.

When that happens, the system isn't broken. The process is. And no amount of customization fixes a process that needed to be simplified in the first place.

5. Bad data

Nothing kills trust in a system faster than data that's wrong.

If a rep pulls up a lead and the phone number's dead or the contact doesn't work there anymore, that's one more reason not to trust it. And once that trust is gone, they build workarounds around it, which makes the data worse, which erodes trust further. It's a downward spiral, and it starts with one bad phone number.

Some of this you can automate. Industry, lead source, that kind of data can often be automated. But plenty of it depends on a rep actually entering what they learned on a call. Required fields matter here for a reason. Skip that step enough times, and you've got a CRM full of gaps instead of answers. And a rep who keeps hitting gaps stops going to the CRM for answers at all.

That's when you start hearing things like: "I keep getting asked how to forecast my deals for this quarter, or what lead sources are working best, and I can't get to that answer." That's not a reporting problem. That's a team that stopped trusting the system enough to put good data into it.

Your dashboards will confirm this. HubSpot shows you the last time a report was viewed and the last time it was edited. Go look. Most portals we open have hundreds of reports and a dozen near-duplicate dashboards, and half of them haven't been touched in months. If nobody's opening the reports, that's not a reporting gap. That's a team that has already stopped trusting what's in them.

6. Workarounds cause tech debt

Sometimes workarounds are necessary to keep things moving. The problem is when those workarounds never get revisited.

• A spreadsheet that started as a stopgap becomes the system of record.
• A workflow someone built for a single campaign never gets cleaned up.
• Critical logic ends up living in one person's head, and when that person leaves, the knowledge goes with them.

One of our clients once put it simply: "We have some Zaps built into it, and there's some weird click-through paths because that's the way we could figure it out."

That's not a system running as intended. That's a team quietly duct-taping around the gaps.

We call this tech debt. It's the accumulated cost of every workaround and shortcut that got the team moving fast in the moment but never got cleaned up. And like financial debt, it accrues interest the longer it sits.

Here's what that looks like in practice. A company needs to launch a new pricing tier quickly. Instead of updating the CPQ logic properly, someone hardcodes a discount rule into a workflow as a stopgap. Six months later, nobody remembers the rule exists. A new pricing change breaks quotes silently because the workflow conflicts with the actual pricing logic. It takes days to trace the bug back to that one workflow because nothing was documented. The shortcut saved a week upfront and cost far more in debugging, lost trust in the data, and delayed the next pricing change.

Tech debt isn't a one-time cleanup. It needs to be tracked and deliberately paid down over time, or it silently taxes every future project you try to run.

7. Poor documentation

Documentation isn't a one-time deliverable. It's a living reference.

Train your team once and walk away, and here's what happens. Six months later, half of them are doing it slightly differently than they were taught, and the other half never got trained at all because they joined afterward. Without something to point back to, "how it's supposed to work" quietly turns into "how everyone happens to be doing it."

New hires have it worse. There's no training left to miss and nothing written down to hand them, so they just learn the system from whoever's sitting closest to them, bad habits included.

8. No clear ownership

For years, the pitch around HubSpot was that it's so easy to use, you don't need an admin. The reality is the opposite. HubSpot has said that the average customer has 9+ tools integrated into their portal. Somebody has to own the decisions that ripple through all of that. When nobody does, it shows up fast.

Without clear ownership, things slip through the cracks. Workflows get built and forgotten. Integrations break quietly. Nobody's watching what's running or why. When we audit a portal, this is one of the first things we check. Go into workflows and look at how many are actually on, how many have errors, and how many are even being used. Then go look at users and roles, and check last login dates. You'll get a real sense of who's using the system and who isn't in about ten minutes.

The red flag we see constantly: fifteen super admins, and when you ask who actually owns the platform, the answer is some version of "kind of everyone." That's not ownership. That's fifteen people making decisions with no one accountable for how they interact.

9. Software and system sprawl

Think about your team's actual day-to-day routine. How many systems do they have to open to do their job? Every additional tool is another decision point, another login, another place data can get out of sync.

This isn't an argument against having multiple tools. It's an argument for thinking hard about where your team actually works from, and how many times a day you're asking them to context-switch just to get something done.

What does success look like?

After running enough of these, the answer isn't complicated: you need internal alignment.

When a team understands why they're doing what they’re doing and how it benefits them specifically, enablement feels like a help instead of a chore. When that alignment is missing, everything gets harder. Training feels like pulling teeth. People stop showing up to sessions. Nobody's being difficult; they just don't see what's in it for them.

We don't wait thirty days to find out which way a project is heading. We're watching from week one. Are deals actually moving through the stages we designed? Are tasks getting completed or piling up untouched? Those are visible almost immediately, and they tell you more than any dashboard will.

The teams who succeed aren't the ones with the fewest problems. They're the ones who understood the why before anyone touched the tool. If you're working through any of this, I’d be happy to talk it through.

Want to get the "How Teams Work" newsletter sent to your inbox? Subscribe Now.