Voice and chat line for accessible ticketing requests
Problem
Requests for accessible seating, a companion ticket, an assistance dog space or a hearing loop arrive through the same phone queue and shared inbox as every other enquiry, mixed in with ticket renewals and parking questions. The agent who picks it up often does not know the venue's accessible provision in detail and forwards the message to someone who does, by email, with no case number attached. A supporter who has contacted the club before has to explain their needs again from scratch, because nothing from the last contact was kept anywhere. Near a fixture, with the queue full, that forwarding step is where requests go quiet, and nobody downstream can show the request was logged in time.
Product idea
A voice and chat line built specifically for access and adjustment requests, kept separate from the general enquiry queue. It asks a structured set of questions drawn from the venue's own accessible provision: wheelchair or amber seating, companion count, assistance dog, hearing loop, step-free route, a quiet space before kick-off. Answers are read back for confirmation, saved against the supporter's record so the next contact does not start from zero, and opened as a case with a named owner at the accessibility desk rather than a forwarded email. Anything outside the checklist, or anything flagged as urgent, hands straight to a person. It does not allocate a specific seat itself; that decision stays with staff who know what is actually available for the fixture.
Who it is for
Contact centre agents who currently field access requests inside a general queue, the supporter services manager who reroutes them by email, and the membership services lead who owns the supporter record.
Possible first version
A single voice and chat entry point with a configurable checklist template per venue, structured capture of access needs and companion details, confirmation read back to the supporter, a case created with an owner and target response time, and a stored profile keyed to the supporter's contact details so the checklist is not repeated next time. Version one does not integrate with the ticketing or seating system: cases are handed to the accessibility desk to action manually, and no seat or ticket is issued by the tool itself.
- Build classification
- Workflow application
- Rough effort
- 4-6 week first release
- Roles involved
- Contact centre agent, Supporter services manager, Membership services lead
- Relevant to
- Professional club, Venue & stadium operator, Federation / governing body, Women's league
- Systems in play
- Telephony and contact centre platforms, CRM and case management, Ticketing platform
- Product framing
- Voice or chat interface
Questions we get asked
What do we need ready before this can even start?
A written checklist of what your venue can actually offer: seating categories, companion policy, assistance dog provision, hearing loop coverage, step-free routes. Most organisations have this somewhere but not in a form anyone can hand over. Writing it down properly is most of the setup work, and it is worth doing even if this tool never gets built, because right now that knowledge lives in one or two people's heads.
Does this replace our ticketing platform or our CRM?
No. It sits in front of both. The case it creates writes into whatever CRM or case management tool you already use, and any seat or ticket action still happens in your existing ticketing platform, done by a person. This is a capture and routing layer for one specific request type, not a replacement for either system.
Supporters with access needs often prefer to speak to a person. Won't routing them into a bot make that worse?
That is a fair concern, and the design has to answer it rather than assume it away. The line offers an immediate handoff to a person at any point, and the point of the structured questions is not to avoid a human, it is to make sure the request is captured correctly the first time so the human who does pick it up has what they need. If testing shows supporters are bouncing off it, that is a sign to change the questions or widen the handoff, not a reason to ignore.
Who ends up owning the cases this creates?
In practice the accessibility desk or whoever currently handles these requests within supporter services owns the case queue, and the supporter services manager owns the checklist as the venue's provision changes over a season. The ongoing time cost is mainly keeping that checklist accurate. If nobody is responsible for updating it when a stand is reconfigured or a facility changes, the tool will keep confirming access that no longer exists.
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.