Do I need a data warehouse to do custom reporting on ServiceTitan?
Not for every question. You need one when a question spans systems, requires history the source system overwrites, or has to be answered the same way every day without a person involved. A single question about one system is better answered with an export. The warehouse earns its cost when it becomes the place where marketing spend, call data and job data can finally sit in the same query.
Three reasons that justify one
Joining across systems is the first. Ad spend, call records, web sessions and job data have no common home, and there is nowhere else to put them together.
History is the second. Operational systems overwrite. A warehouse can keep a dated snapshot of status, pipeline and membership state, which is the only way to answer how something looked at a point in the past.
Repeatability is the third. If a number has to be produced every morning, identically, and read by people who will act on it, it needs to come from something more durable than a saved spreadsheet.
Three reasons not to build one yet
If the question is one-off, a report export answers it faster and cheaper. If the underlying taxonomy is a mess, a warehouse faithfully reproduces the mess at greater expense. And if nobody has agreed on what the metrics mean, the warehouse will simply move the argument into a place that costs money to maintain.
Define the metrics first. It is a slower start and it prevents the most common outcome, which is a warehouse full of technically correct numbers that nobody trusts.
The shape that works
- Raw landing. Store source records as they arrived, untransformed, with the fetch timestamp. When a model is wrong you fix it and rebuild instead of re-downloading years of history.
- Conformed models. One clean table per concept — jobs, invoices, customers, locations, calls, spend — with mapping applied so labels from different sources mean the same thing.
- Snapshots. Daily point-in-time captures of anything whose status changes, which is what makes trend reporting honest.
- A metrics layer. Average ticket, booking rate and revenue per lead defined once, in one place, so two dashboards cannot disagree.
- Presentation. Dashboards and briefs read the metrics layer and never the raw tables.
Start with one question, not one architecture
The projects that succeed pick a single expensive question — usually revenue by marketing source, or capacity versus demand — and build only what answers it, end to end, including the boring parts like monitoring. That produces something people use in weeks, and it reveals the data problems that a design document would never have surfaced.
From there each new question adds a model rather than a project. That incremental path is how custom reporting gets built without a year of preparation, and it is why the modular Bluefrog Intelligence Platform handles common patterns while custom development covers what is specific to your business.
Topics: data warehouse · custom reporting · architecture · BI
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.