Consent and deletion request tracker across the vendor stack
Problem
When a fan or athlete asks to be forgotten, or withdraws marketing consent, the request lands in an inbox and gets logged on a shared spreadsheet with a column for each system: CRM, warehouse, ticketing, the email tool, the customer data platform. A data engineer or the CRM manager then works down the list by hand, logging into each platform separately, because no two systems share an API for this. Some owners reply within a day; others go quiet for weeks, and nobody chases them because the spreadsheet does not flag what is overdue. When a regulator or an internal audit later asks for proof the request was honoured, the evidence is a partly filled spreadsheet and a scattered email thread, and reconstructing it takes longer than the original deletion did.
Product idea
A workflow tool that takes a consent or deletion request as its input, whether typed in directly or forwarded from a form, and creates a tracked case with one task per affected system. Each task is assigned to the person who owns that system: the CRM manager, the data engineer, whoever runs the marketing tool. Owners mark a task complete and attach evidence, a screenshot, an export line, a ticket number, and the case only closes when every task is verified. Tasks left open past an agreed number of days escalate to the case owner automatically. The case produces a single audit record: what was requested, who confirmed what, and when. It does not delete or anonymise data itself; it coordinates the people who do, because writing a generic deletion connector for thirty different vendor schemas is a different, much larger, project.
Who it is for
Data engineers and CRM managers who action the requests, and the Head of data or Head of IT who accounts for how long they took and whether they were completed.
Possible first version
A web form for logging a new request, a configurable list of downstream systems with a named owner for each, automatic task creation per system, email notifications on assignment and on overdue tasks, a checkbox-plus-file-upload for evidence, and a case summary page exportable as a PDF for audit purposes. Out of scope for version one: any direct API connection to a vendor system to perform the deletion itself, and any automatic discovery of which systems hold a given person's data. The owner list is configured by hand, and stays accurate only if someone maintains it as systems are added or retired.
- Build classification
- Workflow application
- Rough effort
- 5-6 week first release
- Roles involved
- Head of data, Data engineer, CRM and CDP manager, Head of IT
- Relevant to
- Professional club, League office, Federation / governing body, Venue & stadium operator
- Systems in play
- Spreadsheets, CRM, Data warehouse and BI tool, Customer data platforms
- Product framing
- Automate a workflow
Questions we get asked
What do we need to have ready before this is worth switching on?
A named owner for each system that holds personal data on an athlete or fan, and it is fine if that list is incomplete on day one. Getting it complete is itself the useful exercise: most organisations do not currently have anyone who could name, without checking, every place a person's record lives. Start with the systems you already know about, add new ones as they come up, and the case history will show you where the gaps were.
We already track deletion requests on a shared spreadsheet. Why change that?
At low volume, honestly, you may not need to. The spreadsheet breaks down once a request sits with an owner who has gone quiet and nobody notices, and once someone outside the team asks for proof a specific request was honoured. If you are handling a handful of requests a year and nobody has ever had to produce evidence for one, the spreadsheet is still the cheaper option.
What happens if a system owner just sits on their task?
The task shows as overdue against the deadline set when the case was opened, and it escalates automatically to the case owner rather than relying on someone remembering to chase it. That does not force the owner to act. It does mean the delay is visible and dated rather than invisible, which is usually enough to change behaviour once a few cases have been escalated in front of the people who sponsor this.
Does it actually delete or anonymise the data itself?
No. It creates and tracks the task; a person confirms it is done and attaches evidence. Writing a connector that can delete a record correctly in thirty different vendor systems, each with its own schema and its own definition of a soft delete, is a separate and much larger undertaking than coordinating who is responsible for doing it. This tool assumes the deletion capability already exists somewhere in each system and focuses on making sure someone uses it.
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.