From the June 10th, 2026, edition of How Teams Work
I’ve seen hundreds of HubSpot portals over the last 10 years, and here’s something that’s (almost) always true: When the sales forecast misses, everyone focuses on the number. Nobody looks at what built it.
By the time anyone catches that the number is wrong, the damage already happened weeks or months earlier.
From our experience, most teams try to fix the forecast when it misses. What they should be looking at is everything upstream that fed it, and the problems that started weeks or months earlier.
When I log into a HubSpot account and the data isn't there, it usually looks like this.
A deal has been in the ‘Proposal Sent’ stage for six weeks. No activity logged. No notes. The close date hasn't been touched since the deal was created. When I ask the rep, they know exactly where it stands. They're working it. They just didn't put any of it in HubSpot.
The honest reason is simple. Logging activity in HubSpot is not what closes deals. Calling the prospect closes deals. So when a rep is busy, the context that lives in their head never gets copied down to the CRM.
But there's a second version of this problem that's just as common. The rep is moving deals through the pipeline, stages are getting updated, but the properties that should be filled in at each stage aren't.
Nobody defined what has to be captured when a deal moves to ‘Proposal Sent’. The Decision maker isn’t confirmed. The Deal amount hasn’t been updated. The Close date wasn’t revised. So the stage moves, but the important data behind it is still blank.
What you end up with is a pipeline that looks active but tells you almost nothing. You can see deals moving. You just can't report on why they're winning or losing, and you definitely can't accurately forecast from it.
These are two different problems that need two different fixes. The activity problem gets solved by making HubSpot the place where the rep's work lives: sequences, email, meeting links, all of it, so that logging happens as a byproduct of the job rather than a separate task.
The properties problem gets solved by defining, stage by stage, what has to be captured before a deal can move forward and building that into the process. Once this is defined, you can then set up the proper guardrails in the system that will require the behavior to happen.
Both have to be solved. Fix only one, and you still won't have the data you need.
HubSpot recently introduced Smart Deal Progression, which analyzes call transcripts and suggests property updates automatically, so the rep is confirming rather than filling things in from scratch. Features like this point to a third lever worth paying attention to. If you've solved the process problem and built the guardrails, AI-assisted data capture can close the remaining gap, not by replacing rep judgment, but by reducing the cost of applying it.
The process isn't defined clearly enough to forecast from
This one is a definition problem, not an effort problem.
The giveaway is when I ask someone to define what it means for a deal to be in a given stage, and I get a different answer from every rep on the team. That's not a data problem. That's a process problem.
What usually happened: someone set up the pipeline when the company was smaller, or copied a generic template, and it has not been updated since. There are no entry criteria. No exit criteria. Reps move deals through based on vibes alone.
The cost shows up immediately when you try to forecast. To build a weighted pipeline forecast that actually means something, you need historical close rates by stage. If ‘Proposal Sent’ closes at 40% in your business, you can use that. But if every rep defines ‘Proposal Sent’ differently, that number is meaningless. You're averaging noise.
The fix is uncomfortable because it's not a HubSpot fix. It's a process conversation. You have to sit down with the sales leaders and define what has to be true for a deal to move from one stage to the next. And if you want real historical data, you have to accept that you're starting over. Whatever's in the pipeline before you did that work, you can't trust it.
But once that work is done, the data starts working for you. With clearly defined stages and consistent rep behavior, you can analyze historical conversion rates by stage and use those numbers to build a weighted pipeline forecast that actually means something. That's when forecasting stops being a guess and starts being a tool.
Finance needs sales data to predict cash flow, recognized revenue, and financial runway. What they usually get is closed-won bookings in whatever format sales used that quarter.
There are three ways companies typically handle the gap between what sales produces and what finance needs, and each one creates its own problems.
The real disconnect is rarely a technical one.
What I usually find is that sales has been modifying deals after close, adjusting amounts, splitting things, changing products, and nobody told finance. Or a rep booked something as annual when the customer is actually paying monthly.
Finance needs to trust that what's in ‘Closed Won’ is clean. Amount, product, contract term, billing start date, all of it. And what I find is that sales was never asked to fill those fields in with any scrutiny because nobody connected those fields to what finance needs downstream.
That's an implementation problem. It's solvable. But someone has to own the conversation between those two departments, and usually nobody wants to.
By the time forecasting breaks, it's rarely just a one-department problem.
Here's the scenario I see most often.
But in HubSpot, the product library either didn't get updated or it only got updated halfway. Now you've got deals built on line items that don't correspond to anything real.
Finance is trying to model recurring revenue and can't because product names are inconsistent, there are duplicates in the catalog, or reps are typing in custom amounts and ignoring the library entirely.
The product team's problem is different. They want to know what's actually selling. Which tiers, which add-ons, what ARR looks like by product line. But if the data in HubSpot is a mess, they can't report on it either.
What almost never happens is someone saying, “Before we change the pricing, let's think about how this needs to be structured in the CRM, what that means for how finance models it, and how product tracks it.” That conversation doesn't happen because those three teams don't have a shared owner. Sales ops updates HubSpot. Finance finds out when the numbers look wrong. Product isn’t in the loop at all.
There's no single fix here. You don't solve one thing, and the forecast is suddenly accurate.
But there is a list worth running through.
If the answer to any of those is no, the forecast problem isn't going to fix itself.
This isn't a HubSpot problem. It's an implementation problem that shows up in HubSpot. The tool will tell you exactly what's wrong. You just have to give it enough to work with.
If you're working through any of this, feel free to reach out. We're happy to share what we're seeing.
Want to get the "How Teams Work" newsletter sent to your inbox? Subscribe Now.
