Complaint cycle-time stall-point report
Problem
A complaint arrives by email and is forwarded from address to address until someone accepts it, often days later and usually only after the supporter emails again asking why nobody has replied. Nobody times the handover itself: not the gap between the email landing and a person opening it, not the gap between opening it and a case being logged in the CRM, not the gap between logging and a first reply. The complaints officer knows which individual complaints were slow because they remember the argument in the forwarding chain, not because any report shows it. When a board member or governing body asks how long complaints take to resolve, the honest answer is that nobody has measured it.
Product idea
A tool that reconstructs the actual path a complaint took from timestamps already sitting in the email forwarding chain and the CRM case record: when it arrived, when it was forwarded and to whom, when a case was opened, when it was first answered, when it closed. It turns that into a cycle-time distribution per stage rather than a single average, so a manager can see that most complaints move quickly once logged but stall for two or three days in the forwarding stage before anyone claims ownership. It does not touch live complaints or intervene in a case. It is a retrospective report run against a batch of closed complaints, built to show where a fix would help rather than guessing.
Who it is for
Supporter services managers and complaints officers who need evidence for where the process breaks down, commissioned by whoever owns complaint handling procedure and wants a case for changing it.
Possible first version
A tool that takes a CSV export of closed complaint cases from the CRM alongside a CSV of the email forwarding chain (sender, timestamp, recipient, extracted per complaint), matches the two by reference number or subject line, and produces a stage-by-stage cycle-time distribution with the slowest stage highlighted. Output is a report, exportable as CSV or a simple chart, not a live dashboard. Version one has no email inbox integration and no CRM API connection: both exports are manual, and matching relies on a reference number the team already assigns.
- Build classification
- Micro-tool
- Rough effort
- 1-2 week prototype
- Roles involved
- Supporter services manager, Complaints officer, Contact centre agent
- Relevant to
- Professional club, League office, Women's league, Federation / governing body, Venue & stadium operator
- Systems in play
- Email and shared inboxes, CRM and case management, Spreadsheets
- Product framing
- Find the bottleneck
Questions we get asked
What do we actually need to have ready before this tells us anything?
A CSV export of closed CRM cases with their timestamps, and a batch of forwarded complaint emails that carry a consistent reference number or subject line to match against. If reference numbers are not applied consistently today, the first job is cleaning that up rather than building the report, because the matching depends on it. A few dozen closed complaints is enough to see whether a pattern exists.
Does this replace the reporting our CRM already gives us?
No. CRM reporting shows what happened after a case was opened, which is usually the fast part. The slow part in most complaint processes happens before a case exists at all, while the email is being forwarded looking for an owner, and that stage does not appear in CRM reporting because the CRM has not seen the complaint yet. This tool is built specifically to surface that earlier gap.
Every complaint is different. Won't that make the report meaningless?
That variation is the point, not a problem for the report. It shows a distribution per stage rather than one average, so a wide spread at a particular stage is itself the finding: it means that stage depends on who happens to see the email first, rather than following a consistent path. A tight distribution elsewhere shows a stage that already works.
Who runs this once it exists, and how often?
It is not a live system that someone has to watch. A complaints officer or an operations analyst runs it periodically, for example against a quarter's worth of closed complaints, and reviews the output alongside the team that owns the complaints procedure. There is no daily upkeep, but someone does need to keep reference numbers consistent for the matching to keep working.
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 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.
- Contact volume forecast for fixture and on-sale daysA dashboard that forecasts supporter contact volume from the fixture calendar and ticketing on-sale dates, so shift rotas are set against the week that is actually coming rather than a normal week.