Your scoring model is only as good as the records it scores. This sounds obvious. Everyone nods along when you say it. And then they build a scoring model on top of a database where 30% of records are missing company associations and the industry field has twelve spellings of "Technology."
Every system you build in HubSpot inherits whatever data quality exists underneath it. Your routing logic, your reports, your lead scores. All of it. There's no layer of abstraction that protects a workflow from the bad data it references.
We call it the silent tax. Nobody puts "data quality" on the board meeting agenda. But it's running underneath every workflow and routing rule in your portal. And the longer it runs unchecked, the more expensive it gets to untangle.
The silent tax on everything else
Here's a pattern we see in almost every portal we audit.
A marketing team builds a lead scoring model. They score on job title, company size, industry, and engagement. It looks solid on paper. But 30% of contact records are missing company associations. Industry is a free-text field that contains "Tech," "Technology," "SaaS," "Software," and twelve other variations of the same thing. Job titles were never standardized, so "VP of Sales" and "Vice President, Sales" and "VP Sales & Partnerships" all score differently.
The scoring model isn't wrong. The data underneath it is. And now sales doesn't trust the scores, so they ignore them. Marketing wonders why the leads they're sending aren't getting worked. The argument starts. Nobody wins because nobody can prove their case.
That's the silent tax. The scoring model cost you a week to build. The data problem underneath it costs you every single day it runs.
Routing has the same problem. We cover this in depth in the automation post, but the short version: a workflow assigns leads to reps based on territory or company size. If those fields are incomplete, leads go to the wrong rep or sit in a queue nobody checks. Speed-to-lead drops from minutes to days. The workflow itself is fine. The data feeding it is the issue.
Reporting is where it gets really visible. If your "Lead Source" field has 47 values because every form, import, and integration created its own variation, your source reporting is fiction. You're making budget decisions on data that wouldn't survive a five-minute audit. And the worst part is, everyone kind of knows this. They just don't have time to fix it, so the fiction becomes the operating assumption.
Where bad data actually comes from
Most teams assume duplicates and bad data are a volume problem. "We just have a lot of contacts." That's almost never the root cause. The root cause is usually one of four things, and most portals have all four happening simultaneously.
The biggest offender is usually integrations syncing without governance. A tool connects to HubSpot, syncs on default settings, and starts creating contacts with incomplete records or overwriting manually corrected fields. The integration was set up during implementation. Nobody reviewed the field mappings. It's been running for eighteen months and nobody's thought about it since.
Bulk imports are the second most common source. Someone uploads a CSV where the column headers don't exactly match HubSpot property names. HubSpot creates new properties or maps to the wrong ones. No dedup rules applied on import. Three hundred duplicates land in the database, each with slightly different data, and nobody notices for weeks.
Forms are sneakier. One form asks for "Company" as a free-text field instead of mapping to the company object. Another captures "Industry" as a dropdown with 8 options while a different form uses a text field for the same question. Every form on your site is a data entry point, and inconsistent forms generate inconsistent records at the moment of creation.
And then there's manual entry. Reps create contacts and deals by hand with no required fields and no formatting standards. One rep types "Acme Inc." and another types "ACME, Inc." and another just types "Acme." Now you have three company records for the same customer with three separate deal histories. Good luck getting an accurate account-level revenue picture out of that.
Property architecture is the part nobody plans
Data quality gets most of the attention, but the structural layer underneath it is property architecture. And almost nobody plans it.
Here's what happens instead. Someone needs a field. They create a custom property. They name it whatever makes sense to them at that moment. They pick a field type. They don't check whether a similar property already exists. They don't document it. They use it for their workflow or report, and then they move on.
Repeat this across every team member, every integration, every implementation partner who's touched the portal over three years. The result is a portal with 400 custom properties, 60% of which nobody uses, 15% of which are duplicates of each other, and the remaining 25% have naming conventions that only make sense if you were in the room when they were created.
The three-field problem
This shows up in almost every portal audit. Marketing tracks lead source using a custom property they created called "Original Lead Source." Sales has a dropdown called "Lead Source (Sales)" that they fill in manually when qualifying. And there's a default HubSpot property called "Original Source" that auto-populates from tracking parameters.
Three fields. Same concept. Different data in each one. When someone asks "where do our best leads come from?" the answer depends entirely on which field the report pulls from. And the three fields disagree with each other because they're populated by different systems at different times with different logic.
This isn't a reporting problem. It's a property architecture problem. And you can't fix it by building a better dashboard. You fix it by deciding which field is the source of truth, deprecating the others, and migrating the data.
What happens when people leave
Every employee who touches HubSpot creates properties. When they leave, their properties stay. When an integration gets replaced, its properties stay. When a campaign ends, the campaign-specific properties stay. Nobody cleans up because nobody has a deprecation process.
HubSpot shows you when a property was last updated. If you run that report, you'll find properties that haven't been touched in two years sitting alongside properties your team uses every day. Those dead properties aren't harmless. They clutter dropdown menus, confuse new team members, and occasionally get selected in reports or workflows by someone who doesn't realize they're abandoned.
How to know if your data is actually broken
Most teams discover data problems accidentally. A rep opens a contact record and sees a duplicate. A manager runs a report and the numbers look off. Someone notices that a workflow sent an email to the wrong segment.
That's reactive. The whole point of data governance is to make it systemic.
Start with an active list. Build one in HubSpot that filters for contacts missing critical properties: no company association, no lifecycle stage, no email, no owner. Check it weekly. If the list is growing, something upstream is creating bad records faster than you're cleaning them up. That tells you where to look.
Then build a workflow that triggers when a contact is created without required fields. The workflow assigns a cleanup task or adds the contact to a queue. This moves you from "someone stumbled across a bad record" to "the system flagged it at the point of entry." It's a small shift that changes the entire dynamic.
HubSpot also lets you require specific properties when a deal moves to a new stage (we cover this in the pipeline post) or when a form is submitted. Use this aggressively. If a deal can't move to "Proposal Sent" without a close date and amount, your pipeline data gets more reliable by default. If a form can't submit without a company name, your contact records start cleaner from day one. These are mechanical guardrails. They don't require anyone to remember to do anything.
And once a quarter, audit your custom properties. Which ones are actively used? Which have zero values? Which duplicate information stored in a different field? Archive what's dead. Consolidate what's redundant. Document what stays and why.
What we do first
Every Fission engagement starts with data. It's rarely the work clients are excited about. Nobody calls us and says "I can't wait to audit our property architecture." They call about scoring, or reporting, or automation. But when we look under the hood, the data layer is almost always the reason those systems aren't performing.
The first step is mapping the dependency chain. We look at which workflows, reports, scoring models, and routing rules reference which properties. That tells us which properties have the highest downstream impact. A property referenced by twelve workflows and three dashboards is more urgent than a property referenced by nothing, even if the second property has worse data quality.
Then we prioritize by impact, not volume. A portal might have 50,000 duplicate contacts, but if those duplicates aren't in active segments or referenced by active workflows, they're lower priority than 200 contacts with missing lifecycle stages that are breaking your lead routing.
We fix the properties that the most systems depend on first. Clean data in high-dependency fields cascades through every system that references them. Clean data in isolated fields fixes one thing.
This isn't a one-time cleanup. The cleanup is step one. Step two is building the governance that prevents the next mess: dedup rules, import validation, property creation standards, field ownership. The goal is a portal where data quality improves over time instead of degrading. Most portals do the opposite because nobody set up the guardrails.
There's a version of this work that feels tedious, and a version that feels like turning the lights on. The difference is whether you're cleaning records in a spreadsheet or restructuring the system so the records come in clean. We do the second one.
The first thing we look at in any engagement is whether the data can support what you're trying to build on top of it. If you're not sure whether yours can, that's what the diagnostic call is for.
