Most HubSpot portals I open for the first time have the same problem. Not the same surface-level complaint, though — the complaints vary. “Our reporting doesn’t match.” “Sales doesn’t trust the data.” “We’re not sure what’s automated anymore.” But underneath those complaints, the portal has been accumulating structural debt since the day it was set up, and nobody has gone back to check the foundation. That’s what a real HubSpot audit is for — not a checkbox exercise, but a structural diagnosis.
I see a lot of companies treat their CRM the way they treat a junk drawer. It works fine when there are four things in it. Three years and 15,000 contacts later, nobody remembers what half the properties mean, there are workflows triggering on lifecycle stages that haven’t been accurate since the second sales hire, and the dashboard the CEO looks at every Monday is pulling from a saved filter someone built in 2022 and never updated.
The audit isn’t glamorous work. But it’s the work that makes everything else — campaigns, reporting, automation, pipeline visibility — actually function.
Start with the property audit
The first thing I do in any portal audit is export the full property list. HubSpot makes this straightforward: Settings → Properties → Export all properties. What comes back is usually revealing.
A typical mid-market portal has somewhere between 200 and 400 contact properties. Of those, I usually find that 30 to 40 percent were created by someone who’s no longer at the company, have no clear naming convention, and aren’t used in any active view, list, workflow, or report. Properties like temp_campaign_field, old_lead_score_v2, or three variations of “industry” that each contain different data for the same contacts.
The instinct is to delete everything that looks unused. I’d push back on that. The first pass should be categorization, not deletion. I sort properties into four buckets: actively used (appears in workflows, reports, or forms), passively populated (has data but isn’t referenced anywhere), redundant (duplicate of another property with a different name), and dead (no data, no references, created more than a year ago). The dead ones can go. The redundant ones need a merge plan. The passively populated ones need a decision — is this data valuable enough to keep, and if so, which property becomes the canonical version?
This usually takes a few hours. It’s tedious. It’s also the step that determines whether everything downstream actually works. It can also be accelerated using Claude’s MCP connection — more to come on that later.
While you’re in the property audit, run a contact database cleanup. Export contacts with no email address, bounced addresses, or no activity in the past 12 months. If they’re not customers and they haven’t opened an email or visited your site in a year, they’re inflating your contact tier and costing you money. HubSpot bills on marketing contacts, and I regularly find 15 to 25 percent of a portal’s contact database qualifies for removal or reclassification to non-marketing. This step alone has saved clients thousands in annual subscription costs.
Audit your lifecycle stages (they’re almost always wrong)
The second thing I check is lifecycle stage definitions. This is where I find the most damage.
HubSpot ships with default lifecycle stages: Subscriber, Lead, MQL, SQL, Opportunity, Customer, Evangelist, Other. I still see these defaults being used, unchanged, three years into a HubSpot contract. The problem isn’t the stages themselves, it’s that nobody has defined what each one means in the context of how this specific company sells.
I see this constantly: a contact downloads a whitepaper and gets marked as an MQL. Another contact requests a demo and also gets marked as an MQL. Those are not the same level of intent, but the CRM treats them identically. Sales gets a list of “marketing qualified leads” that includes researchers, students, competitors doing recon, and actual buyers, all mixed together with no way to distinguish them without opening each record.
The fix isn’t complicated, but it requires a conversation about what each stage means for this business. I think the lifecycle stage definitions should map to observable buyer behavior, not internal marketing milestones. “Downloaded content” is a marketing event. “Requested pricing for a specific product after viewing the case study page twice” is a buying signal. Those should live in different stages.
Rebuilding lifecycle stages usually takes an afternoon of whiteboarding with the sales and marketing leads, followed by a half day of implementation — updating the automation that assigns stages, backfilling historical contacts where possible, and adjusting the reports that depend on stage data.
Workflow audit: the silent problem
Workflows are where a HubSpot audit gets uncomfortable, because this is where you find out what’s been running without anyone watching.
I audit workflows by pulling the full list and sorting by last enrollment date. In a recent cleanup for a SaaS company doing about $12M in ARR, I found 47 active workflows. Of those, 11 hadn’t enrolled a single contact in over six months. Eight were triggering on properties that no longer reflected current process. Three were actively conflicting with each other — one workflow was setting a contact’s lifecycle stage to MQL while another was simultaneously setting it to SQL based on a different trigger, and which one “won” depended on execution timing.
The conflicting workflows are the most dangerous finding in any HubSpot audit. They don’t throw errors. They just quietly produce inconsistent data, and the inconsistency shows up months later when the VP of Sales asks why the pipeline report doesn’t match the forecast spreadsheet.
My approach is to document every active workflow in a simple spreadsheet: name, trigger, actions, last enrollment date, owner (if anyone remembers). Then I sit down with the team and go through them one by one. It’s slow. But I’ve never found a shortcut that doesn’t create new problems.
Integration and data sync audit
The last layer is integrations. Most portals in this range have at least three: the website form integration, an email tool (sometimes HubSpot’s native email, sometimes a third-party sync), and usually one more — Salesforce, a billing system, Slack notifications, a calendar tool.
Each integration creates its own set of properties, its own sync rules, and its own potential for data conflicts. The one I see cause the most damage is the CRM-to-CRM or CRM-ERP sync — typically HubSpot to Salesforce. Field mappings drift over time. Someone adds a new property in one system but forgets to map it in the other. Contact ownership rules conflict. And because the sync runs automatically, nobody notices until a batch of contacts shows up in the wrong owner’s pipeline or a deal amount doesn’t match between systems.
I check integration health by looking at sync errors (HubSpot logs these under Settings → Integrations → the specific integration → Sync health), reviewing field mappings against the current property list, and testing a few records manually to confirm data flows in both directions as expected.
The real deliverable isn’t a clean portal
A clean portal is a byproduct of the audit. The real deliverable is a portal that models how the company actually sells right now — not how it sold two years ago, not how the onboarding consultant assumed it would sell based on HubSpot’s default templates.
It’s highly likely you don’t need new tools. You don’t need a new CRM. You need someone to sit down with what you already have, understand how the business works today, and rebuild the data architecture to match. The cleanup is usually two to three weeks of focused work. The part that takes the longest usually isn’t the technical configuration. It’s getting the right people in a room to agree on definitions.
That’s the unsexy truth about a HubSpot portal audit. The tool works fine. The problem is almost never the software. It’s the decisions that were made (or never made) about how the software should reflect reality. Fix those decisions, and the portal starts telling you what’s actually happening in the business.
An afternoon, a whiteboard, and the willingness to admit the current setup isn’t working. That’s usually where it starts.