Why Your HubSpot Portal Isn't the Source of Truth (Yet)

The tell was a spreadsheet called pipeline_REAL_v3.xlsx.

This was an anonymised composite of a situation I meet often — a mid-sized B2B services firm, a couple of dozen people selling and delivering, a HubSpot portal they'd paid for and set up eighteen months earlier. On paper, adoption was fine. Everyone had a login. Deals existed. Reports could be run. And yet when I asked the head of sales how she actually knew where the quarter stood, she opened a shared spreadsheet, not the CRM. The v3 in the filename told the whole story before anyone said a word: this was the third rebuild of a private source of truth that lived beside the system built to be exactly that.

This is one of the most common and most expensive situations in CRM work. You're paying for a system that isn't doing its job, and the shadow spreadsheets mean your data is now fragmented across places that don't agree with each other. The genuinely interesting part is that the cause is almost never the technology. HubSpot was perfectly capable of everything this team needed. The problem sat upstream of the tool.

Trust is the whole game

A CRM only works if people believe the data in it. That's the entire mechanism, and it's more fragile than it looks. The moment someone opens a record, sees a stale value or an empty field where there should be an answer, and thinks I can't rely on this, they start keeping their own version. Once one person does that, the CRM's data gets a fraction worse — because that person has stopped feeding it — which gives the next person one more reason to distrust it, so they peel off too. The spiral only runs one way.

So the real question was never "is this HubSpot set up correctly?" It was "does the team trust what's in it?" Those are different questions with different answers, and only the second one predicts whether the software gets used. The spreadsheet wasn't the disease. It was the symptom, and a fairly rational one — people had found the CRM unreliable and built themselves something they could depend on. My job wasn't to ban the spreadsheet. It was to make it unnecessary.

What discovery turned up

I spent the first week not touching configuration at all, just watching how deals actually moved and asking people why they did what they did. The causes clustered into the same few categories I tend to find.

Inconsistent properties and stages. Custom properties had accumulated over eighteen months with no one owning the shape of them. There were three fields that meant roughly the same thing — "Lead Source", "Source", and "How did they find us" — populated inconsistently across records. A dropdown for deal type had grown to fourteen near-duplicate values. Reporting on any of it was meaningless, so nobody believed the reports, so nobody bothered to keep the fields clean. The same self-reinforcing loop as the trust spiral, one level down.

Half-built automation. Someone had started building workflows enthusiastically and left them partly finished. Some deals triggered an automated follow-up email; some didn't; nobody could tell you the rule. This is the quiet killer. Partial automation is worse than no automation, because it makes the system's behaviour unpredictable — and people don't trust systems whose behaviour they can't predict. A rep who couldn't be sure whether the CRM had already emailed a client would either email again and look disorganised, or assume it had and drop the ball. Both taught them to stop relying on it.

A pipeline that described a fantasy. This was the deepest cause, and the one that took longest to see. The stages in HubSpot represented how someone had once imagined the sales process — a tidy seven-stage funnel — not how this team actually sold. Real deals here often skipped straight from a first call to a proposal, or sat in a long "warm but not now" limbo the pipeline had no name for. So reps forced their real deals into whichever stage was least wrong, and the data drifted from the truth a little more with every deal logged.

The pipeline wasn't wrong because it was badly built. It was wrong because it described a company that didn't exist.

Data that arrived dirty and never got cleaned. The original import, years back, had brought in duplicates and gaps that were never resolved. First impressions of data are sticky: the team's founding memory of the CRM was "the data's a mess", and no amount of subsequent tidying had displaced it.

The decision: fix the model before touching the tooling

The tempting move — and the one a lot of HubSpot work jumps to — is to build more. More automation, more fancy properties, more dashboards. I deliberately did the opposite first. You cannot automate your way out of a data model that doesn't match reality; you only automate the drift faster.

So the sequencing went like this, and the order mattered more than any individual step.

We started by mapping how the team actually works — not the documented process, not how leadership described it in the kickoff, but how deals genuinely moved, messy limbo stage and all. I sat with three different reps and traced real deals end to end. The seven-stage funnel collapsed to five stages that people recognised, including an honest "nurturing / not now" stage that finally gave the long-limbo deals a home instead of forcing them to lie.

Then we rationalised the properties and pipeline to match that real process. Three overlapping source fields became one, with a controlled set of values everyone understood. The fourteen-value deal-type dropdown became six. This is where a lot of the genuine technical work lives, and it's worth doing slowly. Every field we kept had to earn its place by answering a question someone actually asked.

We cleaned the data once, properly — deduplicated, filled the gaps that mattered, standardised the values — and then, critically, put validation in place so it would stay clean.

Here's the shape of the validation we added at the point of entry, so bad data was caught on the way in rather than found months later in a report:

// Enforced on deal creation/update via a HubSpot workflow guard.
// The goal isn't to nag reps — it's to make the clean state the easy state.
function validateDeal(deal) {
  const problems = [];

  if (!deal.dealType) {
    problems.push("Deal type is required — it drives every pipeline report.");
  }
  if (deal.stage === "proposal_sent" && !deal.amount) {
    problems.push("A sent proposal needs an amount. What did we quote?");
  }
  if (deal.stage === "closed_won" && !deal.closeReason) {
    problems.push("Log why we won — it's how we learn what works.");
  }

  return problems; // empty array === the record is trustworthy
}

Finally, we finished the automation or removed it. Every workflow now either fires reliably for every relevant record, or doesn't exist. There is no third state where a deal might or might not have been chased. Roughly half the half-built workflows were completed; the other half were deleted, because on inspection nobody could say what they were for, and an automation nobody understands is a liability wearing a productivity costume.

Before and after

The change is easier to feel than to measure, and I won't invent numbers for it. But the qualitative shift was unmistakable across the portal.

That last row is the one that mattered. Nobody was ordered to abandon the spreadsheet. It simply stopped earning its keep, because the thing it existed to compensate for had gone.

Re-earning trust is a separate job

Here's a lesson that surprised me the first time and no longer does: fixing the data and the model is necessary but not sufficient. Trust, once broken, doesn't return the moment the underlying problem is solved. The team had eighteen months of learned scepticism, and a clean portal on Monday doesn't erase that by Friday.

So the last phase was deliberate and slightly boring: repeatedly showing the team that the reports now matched what they knew to be true. When the CRM's pipeline number and the head of sales's gut agreed three weeks running, she started to relax. When a rep saw the automated follow-up fire exactly when it should, every time, they stopped double-checking it. Trust came back the only way it ever does — slowly, through repeated evidence that the system is reliable. You can rebuild a data model in a fortnight. Rebuilding belief takes as long as it takes.

Why this kind of work rewards close attention

This is unglamorous, detail-heavy work. It rewards someone sitting with your team, understanding the actual process, and making careful, consistent decisions across the whole portal — not a rushed template rollout that imposes a generic funnel and moves on.

It also rewards plain honesty. Sometimes the right advice is that you're over-configured and need to simplify, or that a feature you're paying for isn't earning its keep and should be switched off. That advice is easier to give when there's no incentive to maximise billable complexity — when deleting half-built workflows counts as a win rather than a loss.

A CRM that's genuinely the source of truth changes how a business runs. The follow-up happens because the system prompts it, reliably. Reporting reflects reality because the data is clean and consistent. A new joiner can be trusted with the CRM because the CRM can be trusted. And the shadow spreadsheets quietly disappear, because there's finally no reason left to keep them. Getting there had almost nothing to do with HubSpot's feature list and almost everything to do with the discipline of matching the tool to a real process and keeping the data honest. Do that, and the platform you're already paying for finally starts doing the job you bought it for.