Metric hotline that answers approved numbers by phone
Problem
On a Sunday morning three hours before kickoff, the commercial director wants last night's concourse spend figure and the analyst who owns that report is not answering their phone. The number exists, sitting in a dashboard that only the analyst has ever logged into, built from a warehouse only the data team can query. Ground staff and coaches hit the same wall from a different direction: the training load figure from Friday's session sits in the athlete management system, but nobody on the coaching staff has a login for the tool that shows it. Everyone ends up messaging the same two or three people, at the hours those people are least likely to be at a screen, and the request either waits until Monday or gets answered from memory.
Product idea
A phone line built around a fixed catalog of approved metrics: attendance, concourse spend, training load, ticket scan counts, whatever the data team chooses to publish. A caller rings in, asks for a metric by name, and the assistant reads back the figure, the time it was last refreshed, and which system it came from. If the figure is older than the threshold the data team set for it, it says so rather than reading it as current. Anything asked that is not in the catalog is logged with the caller's number and forwarded to the data team's queue rather than guessed at. It does not run open-ended queries against the warehouse and it does not write anything back.
Who it is for
Coaches, commercial and matchday operations staff, and venue managers who need a single figure outside office hours; sponsored by the Head of data or Head of IT who owns the underlying warehouse.
Possible first version
A telephone number connected to a speech-to-text front end, backed by a manually configured catalog of ten to fifteen metrics, each mapped to a single query against a nightly snapshot table rather than a live warehouse connection. Each catalog entry has a staleness threshold set by the data team. Unrecognised or stale requests are written to a shared log with caller number and timestamp for morning follow-up. Out of scope for version one: any open-ended natural-language query against the warehouse, live rather than nightly refresh, SMS delivery of results, and integration with a paging or on-call system.
- Build classification
- Workflow application
- Rough effort
- 3 to 4 week first release
- Roles involved
- Head of data, Insight and BI analyst, Head of IT
- Relevant to
- Professional club, Venue & stadium operator, Collegiate athletics, Federation / governing body
- Systems in play
- Cloud data warehouse and lakehouse, Business intelligence and visualisation tools, Telephony and contact centre tools, Athlete management systems
- Product framing
- Voice or chat interface
Questions we get asked
What has to exist before this can answer a single call?
A short list of metrics the data team is willing to stand behind after hours, each one mapped to a query that already runs cleanly, plus an agreed staleness threshold for each. That list is the actual work. Ten well-chosen metrics that are always right beat thirty that might be a day old, and building the catalog usually takes longer than building the phone line itself.
Our analyst already answers these on Slack when they can. Why build a phone line?
Because 'when they can' is the gap this closes. A Slack message sent at ten on a Sunday night still waits for a person to see it. This does not replace the analyst for anything that needs judgement; it only takes the small set of numbers asked for repeatedly and makes them available without a person in the loop, and it hands anything else straight to the same analyst's queue instead of leaving it sitting in a chat thread.
Can it answer questions that are not in the catalog?
No, deliberately. It will not construct a query against the warehouse on the fly or guess at a figure it has not been given. A question outside the catalog gets logged and passed to the data team rather than answered, because a wrong number read back with confidence over the phone is worse than no answer at all.
Who has to keep this up to date once it exists?
The catalog needs an owner, usually whoever already owns the metric definitions, and that person needs to review the log of unanswered questions on a regular cadence rather than let it become a list nobody reads. The nightly snapshot also needs to keep running cleanly, since a staleness threshold only helps once someone notices it firing.
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.