Skip to content
  • There are no suggestions because the search field is empty.

You Bought HubSpot and You're Using It Like an Expensive Excel

The moment you realize something is off

It's Tuesday. Your sales director is on a call with a client who's asking about a project that closed three weeks ago. He doesn't know the status. He opens HubSpot. The deal is there, marked as "Closed Won." Nothing else. No notes. No project status. No invoice information. He mutes the call and sends a WhatsApp to operations: "How's project X going?"

Two months ago you signed a contract for HubSpot. You paid for the licenses. Someone configured it. Your team got training. And here you are, on a Tuesday, with your sales director sending a WhatsApp because the CRM doesn't tell him what he needs to know.

This isn't a HubSpot problem. It's not a discipline problem with your team either. It's something else, and it's worth naming clearly.

What actually happened when you implemented HubSpot

Someone — an internal consultant, a certified partner, a freelancer — opened your HubSpot account and asked a version of this question: "What information do you want to track?"

Your team answered what came to mind. Client name. Deal amount. Stage. Owner. Close date. Maybe a few custom fields someone thought would be useful. They built a sales pipeline with four or five stages. They imported your contact list. They turned on a couple of automations. They handed it over.

What nobody did was design how your business should actually work inside that system. Nobody asked how a sold project moves into execution. Nobody mapped which team picks it up, how they know it landed in their queue, what information they need that sales already gathered. Nobody connected the money — what was invoiced, what got paid, what the real margin looks like — to the deal where the work lives.

So your CRM ended up being a list. A nicer list than Excel, with prettier graphs and an app for your phone. But functionally, a list.

Why this happens to companies that sell projects

If you sold standardized products — physical things with SKUs that ship and get invoiced — HubSpot out of the box would work fine. That's the world most CRM implementations assume. Lead in, opportunity, close, ship, done.

But you don't sell products. You sell projects. Which means the moment a deal closes is not the end of the process — it's the start of the most complex part. Operations picks it up. Someone designs what was promised. Someone executes it. Someone bills against it. The project lives for weeks or months after the deal closes, and during that entire time, your sales team needs to know what's happening because the client is calling them, not operations.

A generic CRM implementation has nothing to say about any of that. The pipeline ends at "Closed Won." Everything after that — the actual work, the actual money, the actual relationship — happens somewhere else. WhatsApp. Excel. Email. The head of operations.

That's why your CRM feels like an expensive Excel. Because for the part of the business where decisions actually get made, it is one.

The trap of thinking it's a usage problem

At this point, the natural reaction is to blame the team. "My salespeople don't fill in the fields. Operations doesn't update the deal. If everyone just used the system properly, it would work."

It's a comforting story because it's a problem you think you can solve with discipline. New rules. Monday check-ins. A report that shames whoever didn't update their deals.

It doesn't work. And it doesn't work for a specific reason: people don't use systems that don't help them do their job. If your operations director has to open HubSpot, find the deal, click into custom fields, and update a status — and that update doesn't help him in any way, doesn't trigger anything, doesn't save him a meeting later — he's not going to do it. Not because he's lazy. Because there's no reason to.

Adoption isn't a behavior problem. It's a design problem. When the system reflects how the business actually runs and makes each person's job easier, people use it. When it doesn't, no amount of policy fixes that.

What a CRM should actually do for a company that sells projects

Picture the same Tuesday call, but in a business where the system was designed properly.

Your sales director opens the deal. He sees the project is in execution, week three of six. He sees the last update from operations — added yesterday, automatically, when the team closed a milestone. He sees that two of three invoices have been paid. He sees there's one open incident that the project manager is handling. He picks up the call and answers the client's question without putting anyone on hold and without sending a single WhatsApp.

None of that requires more discipline from his team. It requires that the deal, the project, the invoices, and the operational work all live in connected places inside the same system. That when operations closes a milestone in their workflow, it shows up on the deal automatically. That when an invoice gets paid in your accounting tool, it reflects on the deal automatically. That when a client raises an issue, it becomes a ticket linked to the project, and the salesperson sees it without anyone telling them.

This isn't a feature of HubSpot. It's an architecture. Someone has to design it before anyone configures anything.

What to do before you buy more software or fire someone

If you're reading this and recognizing your situation, here's the order of things that actually moves you forward.

First, stop assuming the problem is the tool or the team. If you switch from HubSpot to Salesforce or Monday or any other CRM and repeat the same implementation process, you'll be back here in six months with a different logo on the screen.

Second, look at where your operation actually lives today. The WhatsApp groups, the spreadsheets, the email threads, the meetings that exist because no one knows what's happening. Each of those is a symptom of something that should be inside your system but isn't. List them.

Third, before anyone touches HubSpot again, the question that needs to be answered is: how should this business work digitally? What does a deal look like from first contact through execution through final invoice? Who picks it up at each stage, what do they need to see, what do they need to update, and what should happen automatically? That answer is a blueprint, not a configuration. It's done on paper before it's done in the software.

Fourth, only then does anyone build anything. And when they do, what gets built matches the blueprint exactly. No discoveries during implementation. No "we'll figure it out as we go." The team gets trained on a system that reflects how their business actually runs, so they use it because it helps them, not because someone told them to.

The reason this matters now

You can keep running on WhatsApp, Excel, and personal relationships. It worked to get you here. The problem is what got you here is what's now limiting you. Every new person you hire has to learn the informal system from someone who's been there for years. Every client question requires three internal messages to answer. Every month, the margin on your projects is something you calculate after the fact, in a spreadsheet, hoping the numbers are right.

And the more your business grows, the more expensive that informality gets. Not in dollars on a P&L — in attention from you and your senior team, who spend their days resolving things that a properly designed system would have prevented.

The fix isn't replacing HubSpot. It's making HubSpot reflect how your business actually works — which requires someone who designs the architecture first and configures the tool second. If you sell projects, this is what we do: we design the digital version of your operation before we touch the software, so when it goes live, your team uses it because it helps them, not because they have to.