Noovo's whole team now works from one set of Claude dashboards, and every figure shows its definition.
Noovo used to spend leadership meetings working out which dashboard to believe. Now the team opens one reports hub in Claude, and any number they hover over says exactly what it counts. We rolled it out in about a month, on definitions Noovo owns in its own warehouse, and with the numbers settled the team now asks Claude what to do next.
Every figure says which definition it came from.
Hover any number in a Noovo artifact and it shows the semantic model, the metric, how it is grouped and what has been filtered out. Anyone can check what a figure is actually counting before they act on it, and an analyst can trace it straight to the definition in dbt.
The same layer is what Claude answers from when someone asks a question, so a dashboard and a chat answer cannot quietly use different definitions. When a question falls outside what has been defined, Claude says so and falls back to the live connection, and that gap becomes the next thing to model.
One metric had five right answers, and nobody had agreed which to use.
Noovo's funnel metrics lived in HubSpot, a BI tool and a set of data models, and they did not agree. MQL, the count of marketing-qualified leads, showed as roughly 4,200, 6,900 and 7,400 on different dashboards, and as roughly 16,000 on HubSpot's own qualification list. Leadership meetings went on reconciling those instead of deciding where to put the next dollar.
The same MQL concept, five different questions
The spread came from logic, not from bad data.
Noovo's funnel is defined inside HubSpot, with a list holding the qualifying rules and a workflow stamping each contact's lifecycle stage. Two properties of that system explain most of the spread. Stages only move forward, so a contact who became an MQL and then progressed is no longer counted as "in" MQL, which means a count of who is in the stage today undercounts every stage except the last. And list membership is cumulative, so the same person sits in several lists at once, which answers "ever qualified" rather than "here now."
Reports and models had each picked one of those conventions, or a mix, so a cleaner pipeline would have produced cleaner versions of the same disagreement. Noovo's first instinct was a better attribution tool, which was a reasonable idea, but any attribution tool inherits whatever the contacts and definitions underneath it are doing. So the order of work was definitions first, instrumentation second, tools third.
ever qualified
sitting here today
We rebuilt the funnel's logic ourselves, from HubSpot's own logs.
Nobody could point to a document that said how the funnel worked, because the rules lived partly in HubSpot lists and workflows, partly in dbt, and partly inside report calculations. So instead of asking people to remember, we rebuilt lifecycle history directly from HubSpot's property log. That let us replay where any contact sat in the funnel on any date, and it became the single historical source of truth for every funnel number after.
With the history rebuilt, the disagreement stopped being a debate and became a choice. We recommended which count should answer which decision:
Acquisition cohort
Of the people acquired in a period, how many went on to qualify. This is the one that tells you whether a channel is bringing in the right people, so it is the canonical funnel for media decisions.
Transition flow
How many contacts moved into a stage this week or month. It tells the team whether the pipeline is on pace.
Point-in-time
Who is sitting in each stage right now. Useful for working the pipeline, and misleading when used to judge marketing.
Decide each definition once, put it in Noovo's warehouse, and let every tool read it.
A short session to settle the definitions
We brought Noovo the decisions that were genuinely business calls, each with a recommendation: count stages cumulatively rather than by where someone sits today, fold out a stage no one maintained, check whether the "Lead" definition was as broad as intended, and remove a hard-coded cutoff date distorting any historical trend.
One definition per stage, in dbt, with tests
The definitions were written once in the warehouse and tested automatically. The project moved onto GitHub in Noovo's own organization, so changes are reviewed rather than made silently.
An instrumentation audit and tracking plan
We checked the existing tracking end to end, found the double-counting, and wrote a tracking plan with standard events and properties (for example, a content-viewed event that records which carousel, banner and content type), so new site features do not quietly break the data.
HubSpot and paid cost brought in line
Lifecycle stage is set up to follow the payment rather than a person remembering to update it, and campaign cost comes directly from the ad platforms into the warehouse instead of depending on what the agency sends.
Claude on top, as the place the team works
Rather than rebuild the same reports in another BI tool, we put Claude on top of those definitions. It reads the semantic layer first, not raw HubSpot, so the answer to "how many accounts" is the same whoever asks. Noovo's design system and metric definitions are both set up as skills, so every dashboard looks the same and uses the same definitions. Reporting that lived in Looker Studio has moved across, with the last few sales reports being rebuilt now and Looker kept on in parallel until the scheduled weekly sales email can be replicated. Access follows how Noovo already manages data: individual Claude accounts for everyone, view and comment access on other people's artifacts, and data-level permissions set in BigQuery.
Everything sits in Noovo's own repo and cloud account, and Noovo's analyst now reviews and extends it.
The team now asks Claude the questions that used to start an argument.
Leadership meetings used to go on working out which dashboard to believe. With one set of definitions behind every report, the same question gets the same answer whoever asks, and the team can act on it.
Which channels bring in people who go on to qualify, and which only add volume?
Then: Move budget toward the channels whose leads qualify, instead of the ones that look cheapest.
What does a lead cost by channel, and what does each figure include?
Then: Compare channels on one definition before the budget conversation, and not during it.
How much of what we collected was refunded, and which month were those deposits paid in?
Then: Tell a timing effect from a real change before reacting to it.
How long are customers waiting for a build, and when do they start to cancel?
Then: Reach the customers at risk, and plan production, before deposits are lost.
How much lead generation can production actually absorb?
Then: Set lead spend to what the factory can build.
Which sales reps are converting, and where do leads stall?
Then: Coach and reassign on one agreed definition of conversion.
Every one of these reads from the same definitions the dashboards use, so a chat answer and a dashboard cannot quietly disagree.
We used to open leadership meetings working out which dashboard to believe. Now we open Claude and see what to do about it.
The move also showed where the old reports disagreed.
Paid deposit figures did not match between the Looker Studio version and the Claude version, because the two had been built on different definitions, and some definitions were simply out of date (refund tracking had been added later). That was reconciled once, in dbt, instead of being argued about in a meeting.
How we judge "it worked" here: whether two people get the same answer independently, whether people use it without us in the room, and whether disagreements get found in the definitions rather than in a leadership meeting. We have not measured revenue impact and are not claiming any.
Get in touch.
Tell us what you are trying to figure out. If we can help, we will say how. If we are not the right fit, we will say that too, and point you somewhere better.