TicketAse - requirements, system flows and developer handover
A nine-section client requirements list for an event ticketing platform, turned into something a development team could build a version zero from.
The brief
TicketAse began as a Phase 1 requirements document from the platform’s owner: nine numbered sections covering user management and authentication, event listings and organiser creation, ticketing and payments, search, marketing, admin features, venue management, refund policy, and security and compliance.
It was a list of features. What the delivery team needed was different: who uses the system, what happens at each step, and which rules have to hold when a customer buys, gifts or refunds a ticket.
My role
Paid client work in 2025, won through a connection from my time at SELISE. I worked from the client’s requirements material to a version zero - actors, flows, business rules and interface screens - that a development team could build from. The team built from it and took it to the stakeholders. I left the project at handover.
What I did
I kept the client’s brief visible beside the work so every decision could be traced back to the request it came from, and went through each of the nine sections deliberately: specifying, extending, quantifying or challenging it. Then I modelled the system around four actors - customer, third-party organiser, admin and super admin - because most of the disagreements in a ticketing platform are really disagreements about who is allowed to do what.
The output
The end-to-end booking flow and the organiser approval workflow. A role-based admin dashboard with its full sidebar structure. The tickets table to field level with a four-state model - booked, paid, used, refund requested - plus seat-conflict detection and a notification matrix split by user and admin triggers.
Business rules written into the flow rather than listed beside it: full refund inside three hours and partial after six, dynamic QR codes with timed expiry, mandatory acceptance of the refund policy, guest email verification on gifted tickets, and two-factor and multi-channel verification. Finished screens for event list, event detail, search, login, terms, and two separate checkout flows for guest and logged-in users.
Two things were not in the brief at all: a cost breakdown separating subtotal, VAT at 5%, platform fee and discount, and local mobile-wallet payment methods alongside card. A live open-questions log and a separate optional-requirements list went back with the handover.
What happened next
The platform launched and is live at ticketase.com. I left after handover, and it has changed a great deal since - what is there now is the product team’s work, not mine.
One reflection
The detail I am proudest of is a question. Venue management was section 7 of the client’s own requirements, and I wrote back asking why we needed it when capacity can be set at event creation and adjusted later. A requirement was asked for, and I pushed back in writing with a reason. That is the difference between taking an order and doing analysis.