You Bought HubSpot. Your Team Still Runs on Spreadsheets. Here's Why.

The system is live. Nothing changed.

You bought HubSpot. You paid for onboarding. You sat through the demos. Your IT person connected the accounts, your sales lead did the training, and for about three weeks everyone logged in and poked around.

Then your operations manager sent a project update via WhatsApp. Your account executive built the proposal in a Google Doc they emailed around. Your director of finance pulled numbers from a spreadsheet that someone updates manually every Friday — when they remember.

HubSpot is open in a tab. Nobody's in it.

This isn't an adoption problem

The instinct is to blame the team. They're resistant to change. They're too set in their ways. If you just did more training, ran more internal campaigns, maybe hired a HubSpot admin to push adoption — it would stick.

It won't. Not because your team is difficult, but because the system you gave them doesn't reflect how they actually work.

HubSpot, out of the box, is built for a company that sells a product. Something with a SKU. A price on a shelf. A transaction that ends when money changes hands. The pipeline has stages, there's a contact record, there's a deal — and when the deal closes, the CRM's job is done.

Your company doesn't work like that. You sell projects. The deal closing is where the work begins.

What "expensive Excel" actually means

When a company that sells projects implements a product CRM without changing the architecture, here's what happens in practice:

A deal closes. The salesperson marks it won. The CRM says "Closed Won." And then — nothing. Operationally, nothing. Your project manager finds out via a forwarded email or a message in Slack. They start a new project in Monday.com or Asana or a spreadsheet. That project has no connection to the deal in HubSpot. The budget that was sold, the scope that was promised, the client's specific requirements — all of it lives in the salesperson's notes, their email thread, maybe a shared doc if you're lucky.

Two months into execution, the project is running over. Your operations director doesn't know what margin was promised. Your salesperson doesn't know the project is in trouble. The client finds out there's a problem on the call where you were supposed to be celebrating progress.

The CRM has data. It just doesn't have the right data, connected to the right things, in a way that reflects what actually happens in your business.

The problem is architecture, not the tool

HubSpot can do exactly what you need. The issue isn't the software — it's that someone configured it like a product company and handed it to a services company.

A company that sells projects needs a fundamentally different structure. Not different software — a different architecture inside the same software.

In a properly structured implementation, a deal doesn't end at close. It transitions. The salesperson marks it won, and that triggers a handoff process: the operations team gets notified, a project record is created automatically with everything that was sold — scope, budget, key contacts, commitments made during the sale.

Here's what that looks like in practice for each person on your team:

Your operations director opens the project and sees exactly what was promised in the sale — the scope, the budget, the delivery timeline — without calling the salesperson, without reading through an email chain, without a briefing meeting. Everything that was agreed is already there.

Your salesperson opens the deal two months after closing and sees how execution is going in real time: whether the project is on track, whether there are open incidents, what's been invoiced and what's still pending. They don't need to ask anyone. They don't need to send a message. They open the record and know.

Your finance director pulls real margin on any project at any moment — not from a Friday spreadsheet, but from the system, because cost data and revenue data live in the same place and update as things happen.

None of that requires a different tool. It requires someone who understands how your business actually works and builds the architecture to match it.

Why the generic implementation fails every time

Most HubSpot implementations go like this: a consultant — or HubSpot's own onboarding team — asks you what your sales stages are, builds a pipeline, connects your email, sets up a few automations, and calls it done. You pay, you get access, you start using it.

The problem is that nobody asked how your operation works after the sale. Nobody asked who needs to know what when a deal closes. Nobody asked how you track costs against what was sold, or how your project managers communicate status back to the sales team, or what happens when scope changes mid-project.

Those questions determine the architecture. Without them, you get a CRM that tracks deals up to the moment they close — and then becomes irrelevant to 80% of your business.

Your team isn't using HubSpot because HubSpot, as it was built, doesn't help them do their jobs. The Excel spreadsheet does. The WhatsApp message does. They're not being difficult — they're being rational.

What to do before touching the tool again

Before reconfiguring anything, you need clarity on three things:

First, map what actually happens in your business end to end — not what's supposed to happen, what actually happens. How does information move from the moment a lead comes in to the moment a project is delivered and invoiced? Who touches it? Where does it live? Where does it get lost?

Second, define what each role actually needs to see. Your salesperson needs different visibility than your project manager, who needs different visibility than your finance director. The system has to serve all of them — not force all of them into a single view that was designed for none of them.

Third, design the architecture before touching HubSpot. Which objects exist. How they connect. What triggers what. What data lives where. What's the source of truth for each type of information. This design should be reviewable and approvable before a single thing gets configured — because changing architecture mid-implementation is expensive and disruptive.

When those three things are clear, the implementation is fast. When they're not, you get another expensive Excel.

The data you're not collecting right now is the data you'll need most

There's a secondary cost that's easy to miss. Every project that runs through your business without being properly tracked is a project you can't learn from.

Which types of projects run over budget? Which client profiles require the most scope changes? Which salespeople make promises that operations can't keep? Which project templates work well and which ones consistently cause friction?

If that data doesn't exist in a structured way, you can't answer those questions. You manage by intuition and memory. When a senior person leaves, they take that institutional knowledge with them.

A properly architected CRM is also a structured database of how your business operates. That database is what allows you to eventually use AI tools meaningfully — not to generate generic reports, but to ask real questions about your specific operation and get useful answers. Without the structured data underneath, any AI layer is guessing.

The companies that digitize their operations correctly right now are building an operational advantage that compounds. The ones that don't will still be running on expensive Excel in three years.

This is a solvable problem

If your HubSpot implementation isn't working, it doesn't mean HubSpot doesn't work for your type of business. It means the implementation wasn't designed for your type of business. That's a different problem — and one that has a specific solution.

SAP ASAP builds HubSpot implementations specifically for companies that sell projects. If you want to see exactly how the architecture works — what it looks like for a business like yours — the full model is here: sap-asap.mx/forcompaniesthatsellprojects.