Natural language query tool for supporter contact history
Problem
When a complaints officer or membership lead asks how many refund complaints came in last month, or how many chat contacts mentioned a specific promotion, the answer comes from an export of the case management system into a spreadsheet, filtered by whoever has an hour free that day. There is no shared understanding of what the CRM's reason codes actually mean, so the same question gets a different answer depending on who ran the pivot table. Complaint trends by venue, channel or agent live in fields nobody queries together, because doing so means opening three exports and matching case numbers by hand. The question usually goes unanswered, or gets answered late enough that whatever was driving it has already moved on.
Product idea
A query box sitting over the case management export, built to be asked plain questions such as how many complaints in the last 30 days were about seating allocation, or which channel drives the most repeat contact. It parses the question into filters against a defined data model of case fields (date, channel, reason code, status, resolution time) and returns a result table with the underlying case references, not just a number, so an answer can be checked. It reads case data; it does not write back to the CRM, trigger a workflow, or interpret call recordings or raw email text. Where a question cannot be answered from the fields available, it says so rather than guessing.
Who it is for
Supporter services managers, complaints officers and membership services leads who need an answer to an ad hoc question without opening a ticket with IT or waiting on a data analyst; typically sponsored by the supporter services manager.
Possible first version
A web tool that ingests a manually exported CSV of case records from the CRM, with fields for date, channel, reason code, status and resolution time. Staff type a question in plain language; the tool converts it into filters and shows a result table linked back to case identifiers, plus a simple chart where relevant. Saved questions can be re-run against a fresh export. Out of scope for version one: live integration with the CRM, analysis of call recordings or raw email text, and any write-back to the case system.
- Build classification
- Micro-tool
- Rough effort
- 2 week prototype
- Roles involved
- Supporter services manager, Complaints officer, Membership services lead
- Relevant to
- Professional club, League office, Women's league, Federation / governing body
- Systems in play
- CRM and case management, Spreadsheets
- Product framing
- Analyse data
Questions we get asked
What data do we actually need to load before this is useful?
A structured export of your case records: one row per contact with date, channel, reason code, status and resolution time, whatever your case management system already produces for a report. It does not need to be clean. Messy or inconsistent reason codes surface as vague answers rather than breaking the tool, which is often useful in itself: if half your cases are logged under 'other', that gap becomes visible in the first query rather than staying hidden in a spreadsheet nobody opens.
Does this replace our CRM or case management system?
No. It reads an export from whatever you already use to log cases and answers questions against it; it has no way to open, close or edit a case. The case management system stays the system of record. Anyone acting on what the query tool shows, reassigning a case or changing a status, still does that in the CRM as normal. Think of this as a window onto data you already hold, not a second place to manage it.
We already have a spreadsheet with pivot tables that answers most of these questions. Why change?
If that spreadsheet is current, trusted and someone maintains it, this may not add much. The gap it targets is the version of the question nobody built a pivot for: a one-off question asked once, by someone who is not the person who owns the spreadsheet. The value is in not needing to file a request and wait, not in doing anything a determined analyst could not already do with the same export.
Could it tell us why complaints are rising or predict next month's volume?
No. It answers questions against the fields that exist in the export: counts, breakdowns and filters, nothing forward-looking and nothing inferred from call recordings or the free text of an email. If the reason a complaint was logged was never captured as a field, the tool cannot recover it after the fact. That is a case management data quality issue, not something a query layer on top can fix.
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 Customer service & voice agents
- Complaint cycle-time stall-point reportA retrospective report that reconstructs complaint timestamps from email forwarding chains and CRM case records to show exactly which stage of the process is where time actually accumulates.
- Complaint ownership queue for the shared supporter inboxA rules-driven queue that assigns, tracks and escalates complaints arriving through the shared inbox so none sit unclaimed until someone happens to reply.
- Contact reason analytics for supporter servicesA reporting layer that classifies every supporter call, chat and email by reason and shows what is actually driving contact volume, so upstream teams can fix root causes instead of only staffing the queue.