Why HubSpot Isn't Working for Your Project-Based Business (It's Not the Tool)

Your ops director found out about the delay in the client meeting — not in your system

The client asked for an update. Your ops director pulled up the project, saw the last note was three weeks old, and had to say "let me check and get back to you." The information existed somewhere — in a Slack thread, in someone's head, in a spreadsheet that only one person updates. Just not where it needed to be.

You have HubSpot. You've had it for a year, maybe two. Your team uses it — sort of. Sales logs calls. Someone built a pipeline. There are contacts in there. But when something goes wrong on a project, nobody opens HubSpot to find out. They call each other.

That's not a usage problem. That's an architecture problem.

HubSpot was configured for a company that sells products — not one that sells projects

Most HubSpot setups follow the same template: contacts, companies, deals in a linear pipeline, closed-won, done. That model works when selling means shipping something that already exists. When you close a deal, the transaction is over.

Your business doesn't work that way.

When you close a deal, the real work begins. A salesperson who sold a six-month consulting engagement needs to hand off context to the team that will actually deliver it. That team has its own timelines, its own dependencies, its own updates that the client cares about. The deal in your CRM is not "closed" — it's alive for the next six months, and everyone involved needs visibility into it.

A generic HubSpot setup doesn't model that. It marks the deal won and moves on. What happens after the signature lives somewhere else: a project management tool, a shared drive, a group chat. Your CRM becomes a pre-sales tool and nothing more.

The result: three systems that don't talk to each other, and a team that fills the gap manually

Here's what that looks like in practice. Your salesperson closes a project. They send an email to the ops team with the scope. Ops creates a card in Monday.com or Asana. Finance tracks costs in a spreadsheet. The client gets updates from whoever happens to know what's going on that week.

Nobody's doing anything wrong. The problem is that each of those tools was set up independently, for its own purpose, without a shared model of what a "project" means across your business. So when your CEO wants to know the current margin on an active engagement, that number doesn't exist anywhere. Someone has to build it from three sources, manually, in a meeting.

This is the fragmentation problem — and it's not solved by adding more tools or better discipline. It's solved by redesigning how your CRM models your business in the first place.

What a setup that reflects how you actually operate looks like

When HubSpot is configured for a project-based business, a deal doesn't end at close — it enters a post-sale stage with its own pipeline. The ops team gets an automatic handoff notification with everything the salesperson captured: the scope, the client's expectations, the edge cases that came up during negotiation. Nobody has to ask. Nobody has to forward the email thread.

Each project has its own record — not a field on a contact, not a note buried in a deal — a full object with its own status, its own timeline, its own cost tracking. When a senior developer gets pulled off a project and that affects delivery, that update lives in the system. When your salesperson wants to know how a client's engagement is going before their quarterly call, they open the deal and see it. No Slack message required.

Finance can see actual costs against what was sold, in real time, inside the same platform. Your ops director walks into the client meeting already knowing the status — because the system is where the truth lives, not the person who happened to attend the last standup.

What to do if your current setup isn't working

Before touching any configuration, map the gap between what your CRM currently models and what your business actually does. Ask three questions:

• Does your CRM have a record for each active project — separate from the deal that originated it?
• Can a salesperson open a closed-won deal today and see the current delivery status, costs, and any open issues?
• When ops receives a new project, do they get everything they need from the system — or does someone have to brief them manually?

If you answered no to any of those, the page at SAP ASAP shows you what the corrected model looks like — how deals, projects, tickets, and financials connect inside one system — before you commit to anything.