Most reporting problems are capture problems wearing a dashboard.
When four people produce four answers to the same question, the reporting tool is almost never the cause. Either the underlying event was never captured consistently, or nobody agreed what the word in the question means. A better dashboard on top of that produces a faster disagreement.
Thirty minutes · no predetermined package
The disagreement is upstream of the dashboard.
Every figure on a board pack is the end of a chain: an event happened, something recorded it in a field, a definition decided which records count, and a report added them up. A disagreement can enter at any point in that chain, and it almost never enters at the last one.
So the first work is not visualisation. It is writing down what each word means, checking that the event behind each number is actually stored somewhere, and finding the step where a person is retyping figures between systems — because that step is where the two versions diverge.
What this looks like from inside the business.
Two people pull the same number and get different answers, and both can defend theirs.
The monthly pack is assembled by hand and takes days, so it is always looking backwards.
Nobody can trace a closed deal back to what originally produced it.
Forecasts are built on a stage that does not mean the same thing to every salesperson.
Comparing locations or teams is impossible because each records differently.
The dashboards that were built are not opened, because nobody trusts them.
Four mechanisms, and none of them is the software.
No agreed definitions
If qualified lead, opportunity, active customer and churn are not written down, every report silently invents its own. The cheapest thing on this page to fix, and the one most often skipped.
The event was never captured
You cannot report response time if first-contact time is not stored. Most missing metrics are missing fields, and no reporting layer computes a value from data that was never recorded.
Data quality is nobody’s job
Without validation at entry, required fields at stage transitions and someone accountable for the record, the data degrades continuously. Reports then get discounted, which removes the incentive to maintain them.
Reporting was a final phase, not a design input
The questions the business needs to answer determine what the system has to capture. Deciding them after the build means retrofitting fields, which is how you get history you cannot analyse.
Six questions before changing anything.
Definitions at the top, because everything below inherits them.
A dashboard is the last layer, not the project. Each layer here exists because the one above it is meaningless without it.
What we would actually be doing.
Where this has already been built.
Attribution running across five platforms
Server-side, joined on the record that closed, reconciled daily — and reported against invoiced revenue rather than against clicks.
See what we've builtWhy the CRM and the finance system disagree
The four places a revenue figure diverges, and which of them are worth fixing before anyone opens a BI tool.
ReadWhat we do before building a dashboard
The definition workshop, the field audit and the honest answer about which historical years are comparable.
How we workWhat teams ask before they start.
Can you just build us the dashboard?
We can, but if the definitions are not agreed and the fields are not captured, we will be building a faster way to have the same argument. If you want only the dashboard we will build it and tell you in writing which numbers on it we do not consider reliable, and why.
Our historical data is a mess. Is it worth anything?
Often less than people hope, and that is worth knowing early. Part of the evaluation is deciding which history is trustworthy enough to analyse, which needs cleaning, and where the honest answer is to start measuring properly from a date and stop pretending the prior years are comparable.
Do we need a warehouse?
Often not. Native CRM reporting is evaluated first because it is the cheapest and the most maintainable. A warehouse earns its place when data volume, history depth or the number of sources makes direct-connect reporting fragile — and not before.
How long before the numbers are trustworthy?
Definitions can be agreed in days. Capture changes take effect from the date they ship, so the honest answer is usually that the numbers are trustworthy from a date, and comparable to prior years only where we can show the field was populated the same way.
Who maintains this afterwards?
Whoever you decide, and the design changes depending on the answer. If it is your team, the definitions and the maintenance tasks are documented and handed over. If it is us, that is an ongoing arrangement we would rather scope explicitly than leave implied.
Bring the two reports that disagree.
The fastest first conversation starts with the same question answered two ways. We will tell you where the chain breaks, and whether it is even a job for us.