HubSpot portal audit: what is broken and what to fix first
Most HubSpot portals I am asked to "just fix" are not missing a feature. They are lying. The dashboard looks finished. Lifecycle is populated. Closed Won has a number. Underneath, create dates were overwritten on an import, two properties store the same fact, reps skip half the stages, and nobody can rebuild the report from the records. If you have to narrate the number in the meeting, the portal is not reporting. You are.
This page is a HubSpot portal audit: a senior teardown of the portal you already have, a ranked plan for what to fix first, and a written list of what not to rebuild. It is for marketing and RevOps leads who inherited HubSpot, or watched it drift, and who are being asked to implement on top of it anyway. How I implement is a different job. Do not hire that work until we know what is actually broken.
In scope: what an audit is, the signs the portal is lying, what is usually broken, the order to fix it, when to remediate versus start a new portal, the artifacts you walk away with, and how I actually audit. Out of scope: a new implementation (that is how to evaluate a HubSpot implementation partner), a Salesforce to HubSpot move (that is the migration page), a free health check, a 60-minute DIY, and an Academy recap of what HubSpot can do. I will not score the portal and email you a traffic light.
What a portal audit actually is
A portal audit is a written teardown of the HubSpot you are already running. It answers what is broken, what to fix first, and what not to rebuild. The work happens in the portal, on real records, not on a settings screenshot and a score. The output is a ranked plan your team can run, or I can run, after you decide. If the finding only lives in a call, you bought a conversation. You did not buy an audit.
What is in: properties and who owns them, pipelines and lifecycle, workflows as a system, permission sets, reports that leadership quotes, the integrations still writing to records, and who still has Super Admin. I sample contacts, companies, and deals. A tidy settings screen can hide junk in the records.
What is out: building the new architecture, turning on a second wave of workflows, a connector project, and a "health check" that grades you against a template. They are not this job. This page will tell you when implementation is the next step. It will not assume it.
Signs the portal is lying to you
The first sign is behavioral. Reps skip stages because the stages do not match how a deal actually moves. They invent side channels in Slack, spreadsheets, or a personal pipeline, and HubSpot becomes the place they update after the fact. The CRM is then a lagging diary, not the system of record, and every report built on stage is theater.
The second sign is definitional. Closed amount and backlog use two different deal definitions. Finance counts line items. Sales counts the deal amount. Marketing counts something that became a customer in a lifecycle that does not match Closed Won. You can have three true-looking numbers for the same month. None of them will survive a rebuild from the records.
The third sign is historical. A lead-source report looks like everything was born last month. Create dates got overwritten on import. The report is not wrong in HubSpot's logic. The data is. Cleanup first, then backfill. If you skip that, every date-based dashboard is a guess.
The fourth sign is identity. Two contacts, same person. Two companies, same account. Owners who left still sit on open deals. Super Admins who should not be Super Admins. If you cannot say which record is canonical, you cannot say what the portal is telling you.
The fifth sign is social. A dashboard everyone quotes, and nobody can rebuild. If the number requires a priest, it is not a report. It is a story with a chart.
What is usually broken
It is rarely one dramatic failure. It is drift. A template that stayed. A handoff that lost the decision log. Workflows stacked on a data model nobody owns. The same six clusters show up often enough that I look for them on purpose.
Properties nobody can explain
HubSpot will let you create an unlimited mess of fields. Inherited portals often have hundreds, two properties for the same fact, and required fields that reps dummy-fill so a workflow stops nagging them. If nobody can say who owns a property, it is not part of the data model. It is leftover. Automating leftover fields is how the lie gets faster.
Lifecycle and pipelines that do not match how you sell
Default stages are a starting point. Lead, MQL, SQL, opportunity, customer, still sitting there a year later, while the real process lives in Slack, is not a starting point. It is the operating model you accidentally kept. Reps skip what they do not believe. A longer pipeline you skip is not more visibility. It is a place for deals to hide.
Workflows that fight each other
One workflow sets a lifecycle stage. Another sets it back. A third sends the email. Nobody will turn one off because they do not know which one is load-bearing. I read them as a system: which object, which property, which one wins.
Reports that cannot reconcile
No line items, and a revenue report anyway. Dashboards on properties with no definition. Marketing and sales arguing about the same month because they are not looking at the same deal. If I cannot rebuild the number from a sample of records, the dashboard is a symptom.
Integrations still writing junk
The portal is not the only writer. A native connector, an old custom job, or a leftover import still creating duplicates, overwriting owners, or restamping create dates will undo any cleanup you do in the UI.
Leftover Super Admins
Former partner. Former ops hire. A contractor who needed temporary access. If half the company can edit the data model, you do not have a data model. Permission sets exist so view and edit are not the same thing.
What to fix first
A 150-item punch list feels thorough and helps no one. Order matters, and the why is simple: later steps encode earlier ones. If the property is wrong, a workflow makes the lie faster. If duplicates are still landing, associations will not hold. If you build the dashboard first, you will argue about a number you already know is dirty.
First, the data model and duplicates. Name the load-bearing properties. Kill or hide the rest. Decide the unique identifier, usually email for people, and stop creating a second record for the same human. Until that is true, I will not spend time on clever automation.
Second, the failure the team already feels. Missed follow-up. Duplicate outreach. A stage reps refuse to use. Fix the pain they will notice on Monday. An audit that only produces architecture they cannot feel will sit in a folder.
Third, silent pipeline leaks. Deals with no next step. Contacts in lifecycle limbo. Owners who left. These do not show up as a loud complaint. They show up as a forecast you cannot defend.
Reporting last. A dashboard on dirty data still looks like a dashboard. I will not put that in front of executives yet.
When you remediate, and when you start a new portal
Most inherited portals can be cleaned. Remediate when the objects are right enough, the junk is concentrated, and we can name owners. A messy property list is not a reason to throw away the deals. It is a reason to document, duplicate-check, and stop the other writers.
Start a new portal when the architecture is the problem. Wrong objects. Two CRMs pretending to be one HubSpot. Years of unowned properties and workflows nobody will shut off, with no decision log to tell you which ones are load-bearing. A rebuild you have not diagnosed is still not a rebuild. That is this audit. I will say which path I think you are on. I will not sell a new portal because it is cleaner to demo.
If you already want a new portal, we still open this one first.
What you walk away with
You walk away with written findings, not a slide that says opportunity. Each finding names the object, the evidence I sampled, and why it matters. You walk away with a ranked plan: what to fix first, what can wait, what not to rebuild. You walk away with a decision log for the audit itself: what I opened, what I sampled, what I refused to treat as a finding.
That last piece matters. An audit that treats every unused property as a crisis is not honest. I will tell you what I am willing to leave alone. If those artifacts only live in a call, you cannot hand them to the next operator, and you cannot hold me to them. The audit is the document.
How I audit a HubSpot portal
I do the work in your portal. All Gusto is a HubSpot Solutions Partner, est. 2014. Senior only. No junior, no offshore ticket queue. That is the delivery model, and it is on About.
I start with what a deal is. Amount, line items, closed versus backlog. If that is still a debate, every report I open will lie in a different way, and I will say so before we pretend the dashboard is the problem. Then I sample records. A settings screen can look tidy while the contacts are junk. Then I read workflows as a system, not as a list: which one writes last, which one nobody owns. Then I check who else is writing: native integrations, old middleware, imports. Create dates, owners, lifecycle.
I will tell you what not to rebuild. Honest over agreeable. If the portal can be cleaned in place, I will not talk you into a new one.
After the audit
We talk. You decide. The audit is not automatically a build.
If the portal can be cleaned in place, we remediate: data model, duplicates, the failure the team feels, then leaks, then reporting. If the finding is rebuild, implementation is a separate decision. That work is on How to evaluate a HubSpot implementation partner. Do not hire it by default. I will not implement over a mess I just documented.
If you are also moving off Salesforce, that is still a mapping and rebuild problem, not an audit with extra steps. Read the Salesforce to HubSpot migration page if that is the actual job. I will not promise zero data loss on a move.
FAQ
Is a HubSpot portal audit the same as HubSpot's health check?
No. A health check grades you against a generic template and often ends in a list of features you have not turned on. An audit is a teardown of your objects, your records, and your writers. I will not email you a traffic light. I will tell you what is broken in this portal, in this order, and what I would leave alone.
How long does an audit take?
It depends on how many writers are still landing, and whether anyone on your side can say what a deal is. I will not put a fake number of hours on an unscoped portal. After I can see the portal, I will tell you what I need to sample and what the written findings will cover.
Do we have to be in the room while you audit?
You should be available for what a deal is, who owns which properties, and which reports leadership actually uses. I do the clicking. I will come back with findings, not a live-narrated clickpath.
Can you just rebuild instead of auditing?
I can be asked. I will not start. Implementing over an undocumented portal encodes the mess. If you already know you want a new portal, we still sample this one so we do not copy the fight. The audit is how we decide remediate versus rebuild. Implementation comes after that, if it comes.
What if the portal is fine and we just need reporting?
Then the audit will be short, and the finding will say so. More often the report cannot be rebuilt from the records, which means the report is not the job. I would rather tell you the dashboard is not the problem than dress dirty data up as a chart.
Who does the audit?
I do. No junior, no offshore ticket. If you are buying this work from anyone, ask for the name of the person in the portal. The person who can open a deal and explain why the stage exists is the person you are hiring.
Let's talk HubSpot
Tell me what you are working on, and what the portal is doing that you do not trust. I will tell you if an audit is the next step, or if you already know enough to implement, or if you should wait.