Data digest that flags weekly shifts nobody has time to check
Problem
Dashboards exist for attendance, commercial spend and training load, but nobody has time to open all of them every week, so slow drifts go unnoticed until someone asks a direct question. A per-cap spend decline that started two months ago stays invisible until the quarterly commercial review. A training load spike across half a squad sits in a dashboard that staff only open for the named athletes they are already worried about. The data was collected, joined and modelled correctly. The failure is that reading it competes with everything else on a Monday, and by the time anyone looks, the pattern that mattered is eight weeks old and buried under whatever happened since.
Product idea
A scheduled job that runs against a fixed set of already-defined metrics, such as per-cap spend, attendance by fixture type and training load by squad, each week. It flags any metric that moves outside a configured threshold or breaks its historical pattern, and writes a short plain-English note explaining what changed and by how much, with a link to the underlying query for anyone who wants to check it. Each note goes only to the metric's configured recipient rather than to a general distribution list. It does not answer open-ended questions and does not attempt to explain why a shift happened. It surfaces the shift and leaves the investigation to a person.
Who it is for
Insight and BI analysts who own the metric definitions and thresholds, the Head of data who sponsors it, and the department leads who receive a note instead of opening a dashboard.
Possible first version
A scheduled job covering three to five metrics agreed with the Head of data, each with a configured threshold and a fixed recipient. It reads from the warehouse's existing modelled tables, or a manual weekly export while the pipeline is still being trusted, and sends a templated plain-English note when a threshold is crossed, with a link to the query behind it. Version one has no self-serve metric builder, no natural-language question box, and no automated cause analysis. Adding a metric or a recipient means editing a config file, not building a dashboard.
- Build classification
- Micro-tool
- Rough effort
- 10-day prototype
- Roles involved
- Insight and BI analyst, Head of data, Analytics engineer, CRM and CDP manager
- Relevant to
- Professional club, League office, Federation / governing body, Venue & stadium operator
- Systems in play
- Cloud data warehouses and lakehouses, Business intelligence and visualisation tools, Transformation and modelling frameworks
- Product framing
- Analyse data
Questions we get asked
We already have dashboards for all of this. Why build another tool?
The dashboards stay the source of truth; this does not replace them. The gap it closes is that nobody opens a dashboard on a week nothing looks obviously wrong, which is exactly when a slow drift gets missed. The digest is a push instead of a pull: it tells a named person to go and look, rather than waiting for them to remember to check. If your team already reviews every relevant dashboard every week without fail, this has nothing to add.
What has to be true about our data before this is worth building?
The metric needs to already have one agreed definition and a table it lives in. If two departments still report different numbers for the same thing, that is the problem to fix first: a digest built on a disputed metric just automates the disagreement and sends it weekly instead of resolving it. Given a small set of settled metrics, three to five is enough to start, and there is no need to wait for every source system to be connected.
Who has to look after this once it exists?
The Insight and BI analyst who set up the metrics owns the thresholds, and that is real ongoing work, not a one-off. A threshold set too tight sends noise every week and gets ignored within a month; set too loose, it misses the thing it was built to catch. Expect to revisit thresholds after the first few false alarms and again each time a metric's normal range shifts, such as at the start of a new season.
What happens the week a source feed is late or broken?
The digest checks whether the underlying table refreshed on schedule before it evaluates anything against it. If a feed is late or a run failed, the note for that metric says so explicitly and reports no comparison, rather than quietly scoring a stale or partial figure against last week's threshold. A late feed is treated as its own signal worth mentioning, not swallowed into silence.
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.