Do you need a data warehouse, or just better definitions?

There is a predictable moment in a growing business. Reports stop agreeing, someone says "we need a proper data warehouse," and a project starts.

Sometimes that is exactly right. Often it is a very expensive way to reproduce the existing problem in a new location.

The distinction is worth ten minutes of thought before anyone signs anything.

The two failure modes look identical from the outside

Both present the same way: three systems, three numbers, nobody sure which to trust.

But they have different causes.

A definitions problem means the systems are measuring different things and calling them the same word. Marketing counts form submissions. Sales counts records that passed qualification. Finance counts leads that reached a recognised stage inside the accounting period. All three are correct. None of them agree. No amount of infrastructure changes that, because the disagreement is not about data — it is about meaning.

An infrastructure problem means everyone agrees what a lead is, but nobody can produce the number reliably. Exports get run by hand. A spreadsheet holds the join. Data lives only inside tools that expire it after ninety days. The definition is settled; the plumbing is not.

The test

Get the three people who produce the conflicting numbers in a room and ask each to define the metric out loud. Not describe the report — define the metric.

If the definitions differ, you have a definitions problem. Building a warehouse now means encoding one person's definition into infrastructure and giving it the authority of a system, which does not resolve the disagreement so much as hide it behind a pipeline.

If the definitions match and the numbers still differ, you have an infrastructure problem, and a warehouse is a reasonable answer.

Most businesses we are called into for the second turn out to have the first.

What to do about a definitions problem

Write one page. Genuinely one page.

For each core metric — lead, qualified lead, opportunity, won, revenue — record four things: what object is being counted, what filters apply, which timestamp determines the period, and which timezone and calendar that timestamp is measured in.

That last pair sounds pedantic and causes more disagreement than anything else on the list. A lead created at 11pm on the 31st belongs to different months depending on who you ask.

Then get it agreed by the people who own each number. This meeting is uncomfortable, and it is the actual work. Everything technical afterwards is downstream of it.

When a warehouse genuinely is the answer

Several conditions make it the right call, and they tend to arrive together:

Your source systems expire data. Ad platforms aggregate away detail after a window. If you need year-on-year comparison at campaign level, you need to be storing it yourself, and no definitional clarity substitutes for data you no longer have.

You need joins no single tool can do. Ad spend against CRM stage against recognised revenue, in one query. Reporting tools can connect to several sources; they are poor at reconciling contradictions between them.

Reporting is a person's job. When someone spends days a month producing numbers by hand, the automation case is straightforward, and the cost of the manual process usually exceeds the cost of the warehouse within a year.

You need auditability. Regulated reporting, board packs, anything where "where did this number come from" needs a real answer rather than a spreadsheet nobody can reconstruct.

You want history that survives tool changes. When you switch CRM — and you will — a warehouse is the only thing that keeps the old data usable.

The order that works

1. 01Definitions. One page, agreed. Days, not months.
2. 02Identifiers. Make sure a key survives the journey between systems. Without this, a warehouse gives you four tables you cannot join.
3. 03Land the raw data. Unmodified, with arrival timestamps. Storage is cheap; regret is not.
4. 04Model the differences explicitly. Not a single blessed number, but a table showing total, minus duplicates, minus out-of-period, minus junk, equals recognised. When something moves, that table tells you which line moved.
5. 05Then build the reports.

Doing five before one produces a dashboard that is wrong faster.

The uncomfortable version

Sometimes the honest answer to "should we build a warehouse" is: not yet, and the thing standing between you and reliable reporting is a conversation two people have been avoiding.

That is a harder recommendation to sell than a platform, which is part of why it gets made less often than it should. But a business that has done step one and nothing else usually has better reporting than one that has done steps three to five and skipped it.