This one is for the RevOps leads, the marketing and sales ops managers, and anyone who has sat in a review where marketing says pipeline is up, sales swears conversion is down, finance trusts neither, and everyone is quietly certain their own number is the real one.
What: Using Breeze Assistant to run a structured trust audit on the reports you have stopped believing, tracing each suspect number back to its root cause in the underlying data rather than patching the dashboard. The output is a diagnosis for every untrustworthy report, a trust rating for the dashboards leadership actually reads, and a remediation list ordered by how badly each problem is distorting the decisions you make.
Prompt of the week:There is a particular flavour of meeting that anyone in revenue operations will recognise. Marketing presents a pipeline figure. Sales presents a different one. Finance has a third. Nobody is lying, and yet no two numbers agree, so the hour that should have been spent deciding something is spent instead arguing about whose report is right. Do this often enough and something quietly corrosive happens: people stop trusting the dashboards altogether and go back to running the business on gut feel and spreadsheets, which is exactly the state HubSpot was bought to replace.
The instinct, when a report looks wrong, is to treat the report as the problem. Swap a filter, change the date range, rebuild the dashboard from scratch. Sometimes that even appears to work, which is the worst outcome, because it teaches you to keep patching symptoms. The uncomfortable truth, repeated by every serious practitioner writing on this in 2026, is that reports almost never lie. They reflect, faithfully and at scale, the data they are given. Garbage in, garbage out. A dashboard that disagrees with reality is not malfunctioning; it is showing you, accurately, that reality in your CRM is a mess.
The messes are depressingly consistent from portal to portal. Inconsistent source tagging, where one campaign is tagged utm_source=linkedin, another LinkedIn, a third nothing at all, so the channel report fragments into contradiction. A flood of Offline Sources swallowing your attribution because the tracking pixel loads in the page footer, or because an integration creates the contact after the visit and stamps itself as the origin. Duplicate records splitting one person into two, quietly doubling counts and halving conversion rates. Lifecycle stages that mean one thing to marketing and another to sales, so the funnel undercounts or skips steps. Pre-set filters that silently exclude live deals. And the tell-tale sign of a portal that has given up: five dashboards answering the same question five different ways.
None of this is fixable at the dashboard layer, which is why rebuilding the report never works. It is fixable only by tracing the wrong number back to the input that produced it, and that tracing is slow, unglamorous detective work that nobody has a spare afternoon for. It is also exactly the kind of multi-signal cross-checking Breeze can do against your live data in one pass. This prompt turns Breeze into the detective: point it at a report you do not trust, and it works backwards to the root cause instead of forwards from the symptom.
Prompt structure
Paste this into Breeze Assistant and make sure CRM data access is enabled in your AI settings so Breeze can reference your reports, dashboards, properties, fill rates, lifecycle stages, and source data:
Role: You are a HubSpot reporting analyst who specialises in
diagnosing untrustworthy reports. You know that a report almost never
lies, it reflects the data it is given, so when a number looks wrong
you trace it back to its cause, the filters, the feeding properties,
the source tagging, the duplicates, the lifecycle definitions, rather
than rebuilding the dashboard and hoping.
Task: Run a trust audit on the reports and dashboards I do not fully
believe. For each one, trace the suspect number back to its root
cause in the underlying data, assign a trust rating, and give me a
remediation list ordered by how badly each issue is distorting real
decisions. Diagnose the cause; do not just rebuild the report.
Context:
- Company: [COMPANY NAME]
- Industry: [INDUSTRY]
- HubSpot tier: [Marketing / Sales / Ops Hub editions; note if
Marketing Hub Enterprise, since attribution reporting depends
on it]
- The reports or dashboards I distrust most, and why:
[name them, and say what looks wrong, e.g. "the pipeline
dashboard shows a number the Sales Director disputes", "channel
report is mostly Offline Sources", "the funnel undercounts MQLs"]
- Where the numbers are compared against a source of truth:
[e.g. "finance reports actual revenue", "the CRM deal list" /
NONE]
- Known data issues, if any: [duplicates, inconsistent UTMs,
Salesforce sync, manual imports, unclear lifecycle definitions /
UNKNOWN]
- Who reads these reports to make decisions: [leadership / board /
marketing / sales / finance]
Audit the following, in this order:
1. FILTER & DEFINITION LAYER (the report itself)
Before blaming the data, rule out the report's own settings:
- Date logic: is it filtering on create date when it should use
close date, or a fixed range that silently drops live records?
- Object and pipeline scope: is it counting the right pipeline,
the right object, the right record type?
- Filter exclusions: is a lifecycle-stage or property filter
quietly excluding records the reader assumes are included?
- Metric definition: is it counting what its title claims (sum
vs count, unique vs total, amount vs weighted amount)?
2. FEEDING-PROPERTY LAYER (the fields the report reads)
A report can only be as reliable as the properties beneath it:
- Fill rate: for each property the report depends on, what
percentage of relevant records actually has a value? Flag any
feeding property below a usable threshold
- Consistency: is the same concept recorded in different formats
or different fields (e.g. Country as USA vs United States,
region typed free-text)?
- Overwrites: is an enrichment tool or integration overwriting a
good value with a worse one, or blanking it?
3. SOURCE & ATTRIBUTION LAYER
The most common single cause of a distrusted marketing report:
- UTM fragmentation: the same channel recorded under multiple
spellings or cases, splitting one channel into several rows
- Offline Sources bloat: what proportion of records land in
Offline Sources, and what is the drill-down telling you the
real cause is (tracking pixel in the footer not the header, an
integration or import creating the contact after the visit and
stamping itself as origin, untagged links)?
- Note the constraint: Original Source Drill-down 1 and 2 are
system-set and cannot be edited, and are cleared if Original
Source is changed, so the fix is a governed custom Source
property built on top of them, not editing the defaults
4. DUPLICATE & COUNT-INTEGRITY LAYER
- Are duplicate records inflating counts or halving conversion
rates by splitting one person or company across two records?
- Do list, dashboard, and workflow counts of the same segment
disagree, and if so, why (filter logic, membership timing,
record type)?
5. LIFECYCLE & FUNNEL-INTEGRITY LAYER
- Are lifecycle stages defined and applied consistently, or does
the funnel skip stages or undercount because a stage means
different things to different teams?
- Are stage transitions stamped by workflow (reliable) or set by
hand (drifts), and does that explain the funnel's shape?
For each distrusted report, produce a diagnosis that names the most
likely root cause and the layer it sits in. Do not recommend
rebuilding a report until its underlying cause has been identified.
Constraints:
- Diagnose root cause before proposing any rebuild. A rebuilt report
on bad data is just a tidier wrong answer
- Distinguish clearly between a REPORT-LAYER fix (filter, definition)
and a DATA-LAYER fix (the CRM inputs). Say which each remediation
is, because they have very different effort and ownership
- For source and attribution, never recommend editing the Original
Source drill-down properties directly. They are system-managed.
Recommend a governed custom Source property instead
- Order the remediation list by DECISION IMPACT, not by ease of fix:
the issue distorting the most important decision comes first, even
if it is the hardest to resolve
- Do not invent fill rates, duplicate counts, or Offline Sources
percentages. If a figure you need is not visible from the current
context, state: "SIGNAL MISSING: [what needs checking manually]"
- Be honest where a number genuinely cannot be reconciled with the
source of truth, rather than forcing a tidy explanation
Output format:
### I. TRUST SUMMARY
{3-sentence overview: how much of the reporting can be trusted today,
the single most decision-distorting issue, and an overall verdict:
TRUSTWORTHY / TRUST WITH CAVEATS / DO NOT DECIDE ON THESE YET}
### II. PER-REPORT DIAGNOSIS
| Report | What Looks Wrong | Root Cause | Layer | Trust Rating |
### III. DASHBOARD TRUST RATINGS
{For each key dashboard, a rating (RED / AMBER / GREEN) and the one
issue most responsible for the rating}
### IV. REMEDIATION LIST (ordered by decision impact)
| Priority | Issue | Report vs Data Fix | Owner | Decision at Risk |
### V. QUICK WINS vs FOUNDATION FIXES
{Separate the same-day report-layer corrections from the deeper data-
layer work, so nothing stalls waiting on the big fixes}
Why this prompt works, and how to adapt it
Most reporting advice is about building reports. This prompt is about the far more common and far less discussed problem of reports you have already built and no longer believe. The reframing it forces is simple but powerful: a wrong number is a symptom, and the useful work is diagnosis, not redecoration. By making Breeze trace every suspect figure back through five layers to its origin, the prompt attacks the cause instead of the readout, which is the only thing that actually restores trust.
A few things to note about how it is constructed:
It audits from the report inwards, in order. The five layers run from the cheapest, most local explanation to the deepest, most systemic one: the report's own filters first, then the properties it reads, then source and attribution, then duplicates, then lifecycle. That order matters, because roughly a third of distrusted reports turn out to have a filter or a date-logic problem that takes two minutes to fix, and it would be daft to launch a data-cleansing programme before ruling that out.
It separates report-layer fixes from data-layer fixes. These are wildly different jobs. A report-layer fix is a filter change one person makes in five minutes. A data-layer fix is a cross-team effort to standardise UTMs or dedupe records or agree lifecycle definitions. Labelling every remediation as one or the other stops leadership expecting a data problem to be solved as quickly as a filter, and stops a genuine quick win getting buried under the big programme.
It knows how Offline Sources actually happens. The single most common distrusted-marketing-report cause is a mountain of Offline Sources, and the causes are specific and knowable: the tracking pixel sitting in the footer so a fast form-fill beats the cookie, or an integration that creates the contact after the visit and stamps itself as origin. The prompt tells Breeze to read the drill-down for the real cause rather than shrugging, and it hard-codes the crucial constraint that the drill-down properties are system-managed and must not be edited, so the fix is a governed custom Source property, not vandalising the defaults.
It orders remediation by decision impact, not by ease. The natural temptation is to fix the easy things first and feel productive. But a trust audit exists to protect decisions, so the issue distorting the most important decision has to come first even when it is the hardest. A two-minute filter fix on a report nobody uses for anything is worth less than a hard, slow fix on the pipeline number the board sets targets against.
“SIGNAL MISSING” stops invented precision. Some of what the audit needs lives outside what the agent can read: the real fill rate on a field, the integration quietly stamping records as Offline Sources, the one figure finance privately treats as gospel. Rather than let a diagnosis lean on a number it has half-invented, the flag hands that gap straight back to a person. An honest “I cannot see this” is worth far more in an audit than a confident figure, because the confident figure is what sends the whole investigation off chasing the wrong cause.
Adapting it for your portal:
One specific report is driving you mad? If it is a single number rather than the whole estate, add: “Focus entirely on [report name]. It shows [X] but I believe the true figure is closer to [Y]. Work backwards through all five layers and tell me the single most likely reason for the gap, with the check I can run to confirm it.” The output becomes a focused root-cause investigation rather than a broad audit.
Marketing and sales numbers do not match? If the core problem is two teams with two truths, add: “Marketing and sales report different figures for the same thing. Identify where the two definitions diverge, which one is closer to the source of truth, and the shared definition both teams should adopt so the numbers reconcile.” The audit tilts towards definition alignment rather than pure data hygiene.
Attribution is the sore point? If the distrust centres on channel or campaign credit, add: “Concentrate on the source and attribution layer. Quantify the Offline Sources problem, map the drill-down causes, and design the governed custom Source property that would give us a channel report we can trust.” The output leans into the attribution fix specifically.
Running a Salesforce sync? If numbers diverge across the two systems, add: “We sync with Salesforce. Treat sync behaviour as a suspect: flag any report whose number depends on a field that crosses the integration, and tell me where a sync mapping or timing issue is the likely cause of a discrepancy.” The audit adds the integration as an explicit source of error.
Preparing for a board or leadership review? If the stakes are a specific meeting, add: “These reports go in front of the board on [date]. Rate each one RED, AMBER or GREEN for whether I can defend the number if challenged, and tell me what to caveat or fix before then.” The output becomes a pre-meeting confidence check.
Want a quarterly cadence? Save the output and re-run it 90 days later with: “Compare against the output from [DATE] and report on which trust issues were fixed, which reports moved rating, whether the Offline Sources proportion fell, and which new discrepancies have appeared.” That turns a one-off audit into a standing measure of reporting health.
Beyond the prompt:
The audit tells you which numbers to believe and why the others are wrong. Acting on it well comes down to resisting one temptation and honouring one sequence.
Resist the temptation to rebuild first. A distrusted report is almost never a badly built report, so rebuilding it produces a prettier version of the same wrong answer and burns an afternoon doing it. Fix the cause the audit found, then look again; more often than not the original report is fine once the data beneath it is.
Take the report-layer quick wins immediately. The filter and date-logic fixes cost minutes and they rebuild confidence fast, which matters, because a team that has stopped trusting its dashboards needs an early, visible win to start trusting them again. Clear those the same day the audit lands.
Then commit to the data-layer fixes as real projects with owners, not as things someone will get to. Standardising source tagging, resolving duplicates, agreeing lifecycle definitions: these are the fixes that actually move a dashboard from red to green, and they take a fortnight, not an afternoon. The remediation list is already ordered by decision impact, so work it top-down and do not let the easy items at the bottom jump the queue.
Then govern the source of the mess so it does not refill. A one-off cleanup with no governance is a treadmill: the same UTM fragmentation and the same Offline Sources creep straight back the moment attention moves on. Set the custom Source property and its capture rules, agree the lifecycle definitions in writing, and put a light quarterly re-audit in the calendar so the numbers stay trustworthy rather than decaying back to argument.
A report you can defend in a room full of sceptics is worth more than ten impressive-looking dashboards nobody believes. The goal here is not prettier charts. It is the quiet confidence of walking into the review knowing that when someone challenges the number, you can trace exactly where it came from, and it holds.
