Data analyst replaced by a data analyst

The brand had outgrown the one-tool-per-team setup. CS lived in Gorgias. Ops lived in Shopify admin. Growth lived in Slack and Looker. Subscription state lived in Recharge. Several pieces lived in internal databases the engineering team had stood up over the years. When something cross-functional came up — and most of the questions worth asking were cross-functional — the truth was scattered across all of them.

Most teams in this spot do one of two things. They buy a “customer 360” platform that promises a unified view and almost never delivers, because their data isn't clean enough for the platform's assumptions. Or they accept that any non-trivial question requires a data analyst to spend a half-day stitching CSVs together. We did neither. We built the data analyst.

We didn’t replace the data analyst’s tools. We replaced the data analyst, with a data analyst the whole team can talk to.

The interesting questions were all cross-functional. “How many California subscribers churned in the last 30 days after a delivery issue, and what's the LTV impact?” pulls from Shopify orders, Gorgias tickets, Recharge subscription state, and the internal ops database that tracks shipping incidents. Answering it required a data analyst to export from each system, normalize the joins by hand, reconcile the inconsistencies, and write up the result. Tens of hours, every time, for the kind of question leadership wanted weekly.

There was also a data quality problem nobody talked about. The Shopify orders dataset, as exported, wasn't categorized in a way that matched the questions the team actually asked. The team's vocabulary (“delivery-issue churn,” “price-sensitive cancel,” “paused-then-skipped”) didn't map cleanly onto Shopify's native tags. Without a unifying categorization layer, every analysis started from raw rows and rebuilt the same logic from scratch.

We tried the off-the-shelf options. Customer-360 platforms wanted to import everything into their own schema, which assumed our data was cleaner than it was. Reverse-ETL tools could sync data but didn't give the team a way to actually ask questions. BI tools answered known questions well but turned every new question back into a ticket for the data analyst. Each tool was good at one piece. None of them was a data analyst.

Two pieces. First, a unified data layer: Shopify orders, Gorgias tickets, Recharge subscription state, and the brand's internal databases, all pulled into one Postgres with a categorization layer the team actually uses, damaged-shipment cancel, price-driven churn, delivery-issue refund, paused-then-skipped, about 12 categories total. ~280,000 historical orders, joined and categorized once, owned by the brand.

Second, the queryable layer: an MCP (Model Context Protocol) server that exposes the unified dataset and the source APIs as tools, with an LLM on top the team talks to in plain English. Today they ask through Slack; tomorrow they could ask through any LLM surface. The integration is the LLM, not the chat client. The result is, effectively, a data analyst on call, that pulls live data from the source systems, runs the join, applies the categorization, and writes up the answer with sources.

The design choice that did the heavy lifting: the unified data layer lives in our Postgres, not a vendor's warehouse. The team's questions stay answerable in the team's vocabulary, and the categorization logic is visible and changeable without a vendor ticket. The MCP server and the LLM on top are the queryable face of that dataset, the data analyst. The dataset itself is the asset.

Cross-functional analysis that used to consume tens of hours of a data analyst's time, the kind of questions leadership wanted weekly but only got monthly, became plain-English questions answered in seconds. Same depth. Same sources. Same auditability. The data analyst's queue stopped being a bottleneck because everyone on the team could ask the data analyst directly.

The deeper win is the dataset itself. Because the brand owns the categorization, the system answers questions the source platforms didn't anticipate. And because it's a queryable LLM layer rather than a fixed dashboard, new questions don't require new dashboards, they require asking.

If your team's most useful questions are the ones a data analyst has to spend tens of hours stitching together from Shopify, your helpdesk, your subscription tool, and a couple of internal databases, you don't have a tooling problem, you have a data analyst bottleneck. Buying another BI tool doesn't fix it. The shape that does fix it is a unified data layer in your own database plus a queryable LLM layer on top that the team can ask in plain English.

The categorization piece is the part most teams underestimate. Owning the ~12 categories that match how your team actually talks, in your own Postgres rather than a vendor's data warehouse, is what makes the system answer the questions you actually ask, not the questions a vendor predicted you'd ask.