Project scope and contribution described in this case study.
01 / TicketCo Agentic Reservations
The challenge
Help ticketing managers move from a reservation request to a usable seat map and allocation, while making each action understandable within the workflow.
Reading the problem / TicketCo Agentic Reservations
A request needs a visible interpretation.
Agentic reservations connect natural-language intent to seat options, holds and allocation review.
Reservation, seat-map building and AI-assisted allocation are separate prototypes, each needing explicit action scope and visible state.
How can an organizer understand what an agent intends to reserve or allocate?
Evidence: the project account and the attributed artifacts on this page. Process drawings and interaction studies are reconstructed explanations; numerical research or business results are included only where separately supported.
02 / TicketCo Agentic Reservations
The approach
Working prototypes explore the flow between reservation requests, seat-map construction and AI-assisted allocation. This TicketCo work is distinct from the independent SeatMapOS booking platform; shared capabilities do not imply identical infrastructure or a deployed integration.
- Reservation request. Explore a guided reservation workflow.
- Venue layout. Build the seat map for the ticketing task.
- Seat allocation. Use AI assistance to support allocation decisions.
03 / TicketCo Agentic Reservations
My contribution
- Developed working prototypes for agentic reservation workflows.
- Connected seat-map building and AI-assisted allocation to the ticketing experience.
- Applied product discovery, interaction design and hands-on prototyping alongside Thea, an AI productivity assistant for ticketing managers.
The process / TicketCo Agentic Reservations
A direction.
A way to build it.
The agent’s interpretation needs to meet a seat map that an organizer can actually inspect.
A schematic of sequence and overlap, not a dated project schedule.
Frame the reservation intent
Identify what a request specifies and which quantities or allocation preferences remain ambiguous.
Separate options from actions
Keep seat exploration distinct from the reservation or allocation commitment.
Prototype map and conversation
Connect the request summary with visible seats and a reviewable proposed allocation.
Review conflicts and clarification
Explain unavailable choices and incomplete requests before advancing the prototype’s action.
How can an organizer understand what an agent intends to reserve or allocate?
A conversational request can leave quantities, locations or allocation preferences unclear. Before an organizer commits to a reservation, the interface needs to connect the agent’s interpretation to the actual seat options. The map is evidence of the proposal, not decoration beside a chat response.
Journey map / TicketCo Agentic Reservations
See the whole task in context.
Choose a step to connect the person’s intent with the interface and the design decision.
Current intent
Describe the request
Reservation, seat-map building and AI-assisted allocation are separate prototypes, each needing explicit action scope and visible state.
- Interface context
- Reservation request
- Review question
- What selection details must be visible before a reservation action?
Representative task sequence and recovery path, not a measured emotional curve or historical research map.
Behind the experience
The visible task depends on work behind it.
For TicketCo Agentic Reservations, this map connects “Describe the request” to “Confirm the next action”. Read across to follow the task, then select a layer to inspect the interface, design and delivery references behind it.
| Layer | Describe the request | Explore seat options | Review the allocation | Confirm the next action |
|---|---|---|---|---|
| The task | Describe the request | Explore seat options | Review the allocation | Confirm the next action |
| Visible interface | Reservation request | Reservation request | Seat-map options | Allocation review |
| Design checkpoint | Reservation, seat-map building and AI-assisted allocation are separate prototypes, each needing explicit action scope and visible state. | Expose how the request has been interpreted. | Make candidate seats available for inspection. | Show the allocation and the next commitment together. |
| Implementation reference | Identify what a request specifies and which quantities or allocation preferences remain ambiguous. | Keep seat exploration distinct from the reservation or allocation commitment. | Connect the request summary with visible seats and a reviewable proposed allocation. | Explain unavailable choices and incomplete requests before advancing the prototype’s action. |
| Recovery | Unavailable seat selection → explain the conflict → choose an alternative | |||
A reconstructed delivery map: the implementation row summarizes design-process dependencies, rather than claiming to document the original backend architecture.
Inspect options before holding seats.
Reconstructed comparison of design approaches. These are review studies, not a claim that both directions were historically tested or shipped.
What this direction changes
Inspect options before holding seats
Exposes the interpreted constraints and leaves an approval boundary.
Give the proposed allocation a place to be inspected.
These studies separate the request from seat-map exploration and allocation review. They expose where the organizer should be able to compare options, understand selection scope and recover from unavailable seats. They illustrate the prototype’s interaction logic rather than a production reservation rollout.
01 / Reservation request
TicketCo Agentic Reservations⌕
01Reservation request↗
02Seat-map options↗
03Allocation review↗
Explore seat options
Expose how the request has been interpreted.
02 / Seat-map options
TicketCo Agentic Reservations⌕
Describe the requestReservation request
Explore seat optionsSeat-map options ⌄
✓Review the allocation
Review the allocation
Make candidate seats available for inspection.
03 / Allocation review
TicketCo Agentic Reservations⌕
Confirm the next action
- Reservation request
- Review
- Seat-map options
- Review
Confirm the next action
Show the allocation and the next commitment together.
Try the interaction
TicketCo Agentic Reservations / Task & review study
TicketCo Agentic Reservations01 / 03
View 01
Reservation request
Expose how the request has been interpreted.
Keep this context visibleReservation request
Expose how the request has been interpreted.
Starting context
Describe the request
Seat identifiers must agree with the conversation.
Prioritize seat identifiers, quantities and allocation status. Conversational language must connect to the same information shown on the seat map.
Illustrative type-role specimenTicketCo Agentic Reservations
Describe the request.
Confirm the next action.
HeadingSeat-map options
24 / 30 px · regularBodyHow can an organizer understand what an agent intends to reserve or allocate?
16 / 26 px · regularLabelConfirm the next action
12 / 18 px · regularStateUnavailable seat selection → explain the conflict → choose an alternative
12 / 18 px · regularPortfolio-font hierarchy illustration; the source does not establish the exact client font or token scale.
Make the agent’s next action predictable.
What selection details must be visible before a reservation action?
A reservation summary should expose quantities and selected locations in terms the organizer can compare with the map. Otherwise a plausible response can conceal a different allocation.
How should an agent explain unavailable seats or an ambiguous request?
When seats are unavailable, the interface should explain the conflict before suggesting an alternative. Replacing the selection without that explanation would weaken the organizer’s control.
Keep agent intent and map state in sync.
The project includes reservation, seat-map building and AI allocation prototypes. A handoff should identify which experiment a change affects, the selection being proposed and the state expected after the action. Those boundaries prevent one prototype’s capabilities from being assumed in another.
An agent-assisted code change should be checked against the request summary and the visible allocation. Preserve the distinction between exploring an option and committing an operation, including when the request needs clarification.
These are related ticketing experiments, presented separately from the broader TicketCo platform redesign and its production scope.
Accessibility & standards
Access belongs in the design.
For this ticketing experience, prioritize seat-selection alternatives, availability announcements, reservation time limits and recovery without losing a selection.
WCAG 2.2 AA · EN 301 549 · APCA · WAI-ARIA · Platform guidance
Complete the task without a mouse
Define tab order, visible and unobscured focus, named controls, table relationships and error recovery using native semantics and WAI-ARIA patterns.
Understand every state
Pair color with text or icons for selection, warnings and availability. Review text at WCAG contrast thresholds and use APCA alongside font size and weight for readability decisions.
Keep the workflow usable
Review zoom and reflow, 24 × 24 CSS-pixel minimum targets or qualifying spacing, alternatives to dragging, validation and accessible authentication where applicable.
Review scope & standards references
These are design references and review priorities, not a claim that this historical project passed a WCAG audit. Record criterion-level evidence, assistive-technology and device results, unresolved issues and retest outcomes before making a conformance statement.
APCA supplements the WCAG 2.2 contrast checks; it does not replace them. WCAG 3 remains a draft. EN 301 549 v4.1.1 is the latest published edition checked on 6 November 2026; its publication and its formal EU legal citation are separate matters. Confirm the applicable procurement or legal baseline with the client.
Outcomes & scope
What the work delivers.
- Working prototypes for reservation, seat-map building and AI-assisted allocation. The project explores the workflow and interface; production adoption and business results have not yet been measured. The cover illustrates the workflow.
Results are described within the documented project scope. Illustrative studies are identified separately from original project artifacts.
Review & next iteration
What needs to hold up in use.
Use these questions to review TicketCo Agentic Reservations against the behavior the design is intended to support.
- 01
Can an operator correct an interpreted seating requirement?
- 02
Is the held allocation distinguishable from a confirmed result?
Project-specific acceptance questions for a future review, not reported usability-test results.
Reflection / TicketCo Agentic Reservations
What I’d carry forward.
A natural-language request is an interpretation until the reservation rules accept it. The interface should let an operator inspect that interpretation before it becomes an allocation.