Most teams don't have a HubSpot data problem. They have a HubSpot reporting problem.
The numbers going in are usually fine. What breaks is the build: the wrong object at the centre of the report, a property quietly measuring something you never asked for, a chart that flattens the one trend you needed to see. The result is a dashboard nobody fully believes, which is worse than no dashboard at all, because now every meeting opens with an argument about whether the figures are right.
Here is how we build reporting at Uspeh, and the mistakes that cost teams the most trust.
HubSpot's out-of-the-box reports are tempting. A few clicks and you are roughly 80% of the way there. The problem is always the last 20%, and the last 20% is usually the exact thing that made the report worth building. Retrofit a built-in report to reach it and you tend to create more problems than you solve.
So we build custom by default. A custom report grows with the business. A built-in one hits a wall the moment your question changes, and your questions always change.
There are a few specific visualisations HubSpot only offers as pre-built report types, and no custom report will reproduce them. When you need one of those, reach for the pre-built type. Everywhere else, custom wins.
When you build a custom report, the primary source should be the thing you actually want to count. Want contacts broken down by lifecycle stage? Contacts are your primary source. Want deals created per month? Deals are.
Obvious, until it isn't. Getting this one wrong sits behind the most alarming reporting bug we see.
Picture a single deal worth 100k with three contacts attached. Build the report with contacts as the primary source, pull in deal amount, and HubSpot will cheerfully show you 300k.
Nothing is broken. The report answered the question you accidentally asked, which was "show me the deal value sitting against each of these contacts." It counted the same deal once per contact because nothing told it not to.
The fix lives in the setup, not the data. Choose the object you truly want to measure, and slow down the moment you start combining objects. When you need genuinely layered filtering, a list or segment is usually more flexible than a report: build the segment first, then report on membership.
Native properties like Create Date live on contacts, deals, and companies, all under the same name. Pick the wrong object's version and your report measures something you never intended. Everything looks correct. It is simply answering a different question.
This is the most common reason a report looks broken, and it catches experienced builders reworking old reports as often as it catches clients. The fix takes seconds: click the pencil on the field and confirm which object the property belongs to. Then name the report and label the fields clearly, so the next person doesn't fall into the same hole.
A report can be technically perfect and tell you nothing, and usually the chart is to blame. Match the visual to the decision it is meant to support:
One trap worth naming: when large and small numbers share an axis, the small series flattens into a line that looks like nothing is happening. Fix the aspect ratio, or split it across two reports.
Say most of your contacts land on a Monday. The instinct is to staff the weekend to catch the rush. Drill into original source, though, and the story can collapse. Some of those Monday contacts were an import. Others were weekend emails that synced first thing and got stamped Monday.
The number was real. The conclusion would have cost you a rota change for nothing. Validate as you build, especially once filters and nested breakdowns start stacking, because one shaky assumption early gets inherited by every layer above it.
Reliability earns trust. Polish signals it. Set the report colours to the client's brand. Format currency properly. Put the legend where the eye already goes. Show percentages next to charts so proportions read at a glance. None of this changes the maths. All of it changes whether the person looking at the dashboard believes it was built for them.
A dashboard is doing its job when someone can act on it without ringing you first to check the figures. That is the bar, and most reports that almost work miss it for one of the reasons above, not because the underlying data is wrong.
If you have quietly stopped trusting a dashboard you rely on, that is a build problem, and build problems are fixable. As a HubSpot Platinum Solutions Partner, that is the work we do at Uspeh.
The usual cause is the wrong primary object. If contacts are the report's primary source and you pull in deal amount, HubSpot counts the same deal once for every associated contact, so a single 100k deal linked to three contacts reads as 300k. Rebuild the report with the object you actually want to measure as the primary source.
Default reports get you most of the way in a few clicks, but they hit a wall the moment your requirements change. Build custom by default so the report can grow with the business. The exception is a small set of visualisations HubSpot only offers as pre-built types, where you use those instead.
Most often you have picked the wrong object's version of a shared property such as Create Date, which exists on contacts, deals, and companies under the same name. The report then measures something you never intended. Click the pencil on the field and confirm which object the property belongs to.
Choose the right primary source, confirm each property sits on the object you mean, validate as you build rather than at the end, and pick a chart that serves the decision. The test is simple: a dashboard is working when someone can act on it without ringing you to check the numbers.