Warehouse query assistant that answers questions in plain English
Problem
An insight analyst spends part of every Monday pulling the same CSV exports from the ticketing platform, the till system and the CRM, then rebuilding the same joins in a spreadsheet, because a department head wants a number by lunchtime and getting it from the warehouse directly takes longer than starting again in Excel. A simple question, such as how spend per fan changed after a schedule announcement, means finding the one analyst who knows which of three attendance definitions is the right one and waiting for them to be free. Two departments already report different attendance figures for the same fixture and both can defend their number, because no one has ever had to reconcile them for a one-off question that will never be asked again.
Product idea
A chat-style query tool that sits over the warehouse's transformation layer rather than the raw tables. A department head or analyst asks a question in plain English; the assistant maps it to one of the metrics the data team has already defined (attendance, spend per fan, training load, ticket sales), runs the query, and returns the answer with the SQL and source tables shown alongside it. If the question needs a metric nobody has defined yet, it says so and logs the request instead of guessing a join. It does not write back to any source system, does not replace the curated dashboards used for recurring reporting, and does not answer against tables the data team has not exposed to it.
Who it is for
Insight and BI analysts fielding ad hoc requests, department heads who need a number without waiting for an analyst, and the Head of data who sponsors it and decides which metrics are exposed.
Possible first version
A chat interface connected to a fixed set of five to ten metrics already defined in the transformation layer, covering attendance, spend and one performance measure. Every answer shows the SQL used and the source tables it drew from. Questions outside the defined metric set are logged for the data team rather than answered. There is no write-back to any source system, no embedding inside the existing business intelligence tool, and no connection to systems outside the warehouse in this first phase; those come later if the curated set proves useful.
- Build classification
- Platform module
- Rough effort
- 10-14 week first phase
- Roles involved
- Insight and BI analyst, Head of data, Analytics engineer
- Relevant to
- Professional club, League office, Federation / governing body, Collegiate athletics
- Systems in play
- Cloud data warehouses and lakehouses, Transformation and modelling frameworks, Business intelligence and visualisation tools
- Product framing
- Analyse data
Questions we get asked
What do we need in place before this is worth starting?
A transformation layer with a small number of metrics already defined and agreed, not just raw tables landing in the warehouse. If attendance or spend still means three different things depending on who you ask, that gets settled first, because the assistant can only be as trustworthy as the definition it is querying. Five to ten well-defined metrics are enough for a first phase; a full semantic layer covering everything is not a prerequisite.
Does this replace the business intelligence tool we already pay for?
No. Your business intelligence tool stays the system for scheduled and recurring reporting, and dashboards built there are still the reference when a number needs to be trusted repeatedly. This is for the question that will only be asked once, or asked by someone who would otherwise wait for an analyst to be free. If a question keeps coming back, that is a sign it belongs in a dashboard, not a reason to keep asking the assistant.
Our analysts already know how to write this SQL. Why build another tool?
They do, and that is exactly the bottleneck: every ad hoc question currently has to go through one of a small number of people who know the joins. This does not remove the analyst from the loop. It removes them from questions a defined metric can already answer, and leaves them for the ones that genuinely need judgement. If your analysts are rarely the constraint on ad hoc questions, this is not worth building yet.
What does it deliberately refuse to do?
It will not answer a question by writing a new join on the fly, and it will not touch a table the data team has not exposed to it. It has no access to write back into the ticketing platform, the CRM or any source system, and it does not attempt real-time answers during a live event. Where a question falls outside the defined metrics it says so and records the request, rather than producing a number nobody can vouch for.
Is this your workflow?
Tell us one sports workflow that still runs on paper, spreadsheets, WhatsApp or an outdated system. We will map it and show you what a simpler product looks like.
Tell us about itMore in Data platform & engineering
- Access permission drift monitor for warehouse and reporting toolsA monitor that compares entity access rules across the identity provider, warehouse and reporting tool, and alerts a named owner when they drift out of sync.
- Attendance reconciliation report across ticketing and till systemsA reconciliation report that turns a ticketing export and a till export for the same fixtures into one defensible attendance and spend figure, with the variance between them shown and explained.
- Chat intake assistant that triages ad hoc data requestsA chat assistant that answers a data request instantly when the metric already exists, and turns anything new into a structured, tracked ticket instead of a message lost in a chat thread.