What is ETL, and does a service business actually need it?
ETL means extract, transform, load: reshape the data before storing it. ELT loads raw data first and transforms it afterward inside the warehouse. ELT has largely won because keeping the raw copy lets you change a definition and rebuild history. Every business that reports across more than one system does this work; the only question is whether it is deliberate or hidden in spreadsheets.
Where the T happens, and why that matters
In classic ETL, data is reshaped in flight and only the finished version is stored. It is efficient and it throws away your ability to change your mind. If the definition of revenue changes next quarter, you have to re-extract everything from the source, assuming the source still has it.
In ELT, the raw payload lands first and transformation happens afterward in the warehouse. Rebuilding a metric across three years becomes a query rather than a project. For businesses whose definitions are still settling, which is most of them, that difference is decisive.
The transform is where the business logic lives
People treat the T as a technical step. It is not. It is where every argument your company has about numbers gets resolved, permanently, in code.
- When revenue counts. At booking, at completion, at invoice, or at payment. Pick one per metric and name it.
- What a lead is. A call over a duration threshold, a form submission, a created contact, or a booked job.
- Timezone and business date. One reporting calendar for everything.
- Deduplication and identity. Which records represent the same customer or the same job.
- Exclusions. Warranty calls, internal test records, cancelled work, inter-company transfers.
Rebuildability is the real test
Here is the question that separates a durable data setup from a fragile one: can you regenerate every number in every report from raw stored data, without calling any vendor API again? If yes, definitions can evolve and mistakes are correctable. If no, your reporting history is frozen at whatever you happened to believe when you built it.
That property is worth more than any particular tool choice, and it is the backbone of the reporting we build for revenue intelligence.
The practical shape for most service businesses
Three layers, no more. Raw, where payloads land untouched. Modeled, a small set of clean tables such as customers, jobs, invoices, calls and spend, where the definitions above are applied. Reporting, which reads only from modeled tables.
Dashboards and AI both read the modeled layer, never raw. That single rule is why an AI analyst and a human analyst produce the same number for the same question, which is the minimum bar for anyone trusting either of them.
Teams get into trouble when a report reaches back into raw data because the modeled layer was missing a field. It works, it ships, and now one number is computed differently from all the others. Add the field to the model instead, even when it takes an extra day.
Topics: ETL · ELT · data modeling · warehouse
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.