Case study / 01

Guest ServicesPlatform

One workspace for the moments that cannot wait.

A unified operational platform that brings together box office, customer support and venue operations so teams can resolve issues, move faster and never lose context.

Role: Senior Product Designer — led Guest Services design
Product: Guest Services Platform
Surfaces: Web Application
Timeline: 6 months

One workspace for the moments
that cannot wait

Guest Services is the operational workspace Cosm venue teams work in before, during and after an event. It brought fragmented operational actions into one shared system for Box Office, Customer Support and Venue Operations.

The design challenge was not to make an operations tool look better. It was to make one product serve three roles with different permissions, different pressures and a shared need for the same guest record — without becoming three products wearing one shell.

The operational gap

Before the platform, a single guest issue was assembled by hand from several systems that did not know about each other.

Context switching
Resolving one guest issue meant moving between separate tools, each holding a different fragment of the same order.
Manual handoffs
Work passed between Box Office, Support and Venue Operations by message and memory rather than by shared state.
Inconsistent resolution
The same issue was resolved differently depending on who picked it up and which tool they reached for first.
Information loss
What had already been tried, refunded or promised did not reliably travel with the guest between teams.

Before

Fragmented tools, separate teams, manual handoffs

Box Office
Customer Support
Venue Operations

Ticketing tool
Refund tool
Scan / access system
Payments
Spreadsheets & notes
Email threads

After

One shared platform connecting roles, guest context and workflows

Box Office
Customer Support
Venue Operations

Guest Services Platform

Guest Lookup
Refunds & Credits
Ticketing
Non-Ticket Items
Venue Dashboard

Three roles,
one source of truth

The same record, read three different ways. Each role needs a different part of it first — and none of them can afford to wait for another team to look something up.

Box Office
Sell, reissue and correct at the window
Works in front of a waiting guest. Needs the order, the seat inventory and the payment adjustment in one place, with holds and offers visible before committing.
Ticketing and inventory
Customer Support
Resolve with the full history
Picks up an issue mid-story. Needs what has already been tried — refunds issued, credits applied, seats released — attributed and time-stamped, so nothing is repeated or contradicted.
Guest Lookup and refund history
Venue Operations
Read the room while it happens
Judges an event in progress. Needs scan status, sold and capacity totals at a glance, and the ability to open a single order without leaving that view.
Venue Dashboard

Understanding the work
behind each request

I shadowed live bookings and interviewed 4 support agents to understand staff ticketing workflows. I then evaluated revised flows through walkthroughs with 3 agents, comparing task time and effort with the earlier process.

Shadowing
Live bookings
Staff ticketing as it actually ran during booking sessions, rather than as it was described afterwards.
Interviews
4 support agents
How a single staff ticketing request is worked from first contact through to resolution.
Walkthroughs
3 support agents
Revised staff ticketing flows, compared against the earlier process on task time and effort.

Scope: staff ticketing inside Guest Services. My separate consumer-facing work on venue, location and seat selection is a different project and is not covered here.

One connected
operational journey

Five capabilities in the order an issue actually travels — find the guest, put it right, reissue, account for what is not a ticket, and watch the room while it happens.

Guest Lookup

Operational need: A guest offers whatever detail they have — a name, an email, a card, an order number.
Key decision: Every identifier is a first-class entry point rather than one canonical search with fallbacks buried behind it, so the search matches how the conversation actually starts.
Why it holds: The record opens once and stays open. Nothing downstream asks the guest to repeat themselves.

Refunds & Credits

Operational need: Money movement under time pressure, with approval limits and an audit obligation.
Key decision: Refunds work at two scales on one model: a single order, and a whole event at once, where refund and Cosm Credit amounts stay editable per guest before anything commits.
Why it holds: Scan status and transaction total sit in the same row as the amount being refunded, so the operator judges each case without leaving the list.

The Bulk Refunds module: a customers summary table listing email, order number, invoice ID, scan status and transaction total, with editable refund and Cosm Credits amounts per row, selection checkboxes, and counts for total, refunded and partially refunded guests.

Ticketing

Operational need: Issue, exchange and reprint against live inventory during an event.
Key decision: Ticket types, offers and operational holds share one surface, so availability and its reasons are read together rather than reconciled between screens.
Why it holds: Holds placed for production, industry, sales or executive use are part of the same inventory view, so what is unavailable and why are answered in one place.

Non-Ticket Items

Operational need: Not everything sold at a venue is a ticket, and finance still has to reconcile it.
Key decision: A custom line item — SKU name, quantity, price, guest email, internal notes — with its own confirmation email, history and separate export, rather than forcing non-ticket revenue through the ticket model.
Why it holds: Finance and reporting stay aligned without operators keeping a parallel spreadsheet.

Described flow

Non-Ticket Items sits in the module rail beside Mobile Ordering, Credits and Deposits. An operator adds a custom line item — SKU name, quantity, price, guest email and internal notes — which sends its own confirmation email and carries its own history and export, separate from the ticket model. Described from the module’s documented behaviour; no product screen is shown in its place.

Venue Dashboard

Operational need: Operations needs the state of the room, not a list of rows.
Key decision: Scan state is carried by colour across the seat map with totals held above it, and any order opens in a panel beside the map rather than replacing it.
Why it holds: One view serves the supervisor watching the venue and the operator solving a single seat.

Two of them, close up

Staff ticketing and transfers are where the day is actually spent. Both are shown here as the operator meets them, with the interaction decisions that shaped them marked on the screen.

Example A — staff ticketing

Issuing against a live event

The task: A staff member sells or reissues for an event already on sale: the right ticket type, the right price, the right number of seats, usually with a guest waiting.
Before the platform: Availability, pricing and any adjustment previously sat in separate tools and spreadsheets, so the price a guest was quoted and the price the system held were reconciled by hand.
The decision: Ticket types, live availability and the offers that apply to them share one surface. Applying an offer confirms in place and rewrites the price on the row, and the offers that were not chosen stay listed so another can be tried without unwinding the sale.
Why it matters here: The operator is mid-sentence. The figure they read out has to be the figure the system will charge, and changing their mind cannot cost them the cart.

The change confirms itself
Applying an offer names the offer back to the operator instead of silently changing a number further down the page.
The old price stays visible
The original rate is struck through beside the new one, with remaining availability on the same line — so the discount and what is left of the inventory are read together.
The alternatives stay on the table
Offers that were not applied remain selectable, so swapping one for another is a single action rather than an undo and a restart.

Example B — transfers and refunds

Moving a ticket, or putting a charge right

The task: A guest wants a ticket moved to someone else, or wants money back — frequently while the event is running and while someone else is already waiting.
Before the platform: The same request previously moved between email, spreadsheets and separate tools, so what had already been promised, refunded or released did not reliably travel with the guest.
The decision: One order detail carries the outcomes as separate, explicit choices — refund, release the seats, or both — with the reason and the approval condition stated before anything commits, and each completed action written back attributed and time-stamped.
Why it matters here: Money and seats are irreversible in the guest's eyes the moment they are told. The operator has to promise precisely, and whoever picks the issue up next has to see what was already done.

Ticket Purchase Detail with the refund action panel: refund or release seats, a reason selector, an approval note stating that anything over two hundred dollars needs special approval, and a refund history listing each action with the operator who performed it.

Three outcomes, not one button
Refunding, releasing the seats and doing both are distinct choices, because they are distinct promises to the guest and distinct effects on inventory.
The limit is stated before the action
The approval threshold and a required reason sit in the panel itself, so an operator learns the constraint while deciding rather than after submitting.
A transfer is a state, not a message
Each ticket in the order shows the person it was sent to and whether they have accepted it, so a partly transferred order reads correctly instead of looking unfinished.

The trade-offs
behind the system

Four decisions, each with something given up for it. In a tool used during a live event, the cost of a decision matters as much as its intent.

01
Guided, not cluttered
Constraint
One workspace had to absorb the work of several separate tools without becoming those tools stacked in a sidebar.
Decision
A fixed module rail with a single active context, and density placed only where an operator is comparing values — inventory, totals, refund history.
Trade-off
Fewer things are visible at once than a power user might want. The cost is paid deliberately: the next action stays findable when the room is busy.
02
Trust through feedback
Constraint
Refunds, releases and reissues are irreversible in the guest's eyes the moment they are told.
Decision
Every state-changing action states its reason, its approval condition and its consequence before it commits, and writes an attributed record afterwards.
Trade-off
It adds a step to the fastest possible path. In exchange, an operator can promise something and be right.
03
Resilient by design
Constraint
Partial states are normal here: partially scanned orders, partial refunds, pending and accepted tickets in the same order.
Decision
Partial is a first-class state everywhere it can occur, rather than an error case bolted onto a binary model.
Trade-off
More states to design and test. The alternative is an interface that lies about the most common real situation.
04
Built for real pressure
Constraint
The work happens during a live event, often standing, mid-conversation, with a queue.
Decision
Shared interaction patterns across modules, designed to reduce relearning for staff who may work occasional events and move between modules mid-shift.
Trade-off
Consistency sometimes beat the locally optimal layout for a single module. Across a shift, the consistency wins.

Designed against

Multiple legacy integrations
Real-time inventory and pricing
Strict compliance and audit needs
High-stakes, time-sensitive use
Multiple roles, different permissions

Validation
and iteration

Revised staff ticketing flows were evaluated in walkthroughs with 3 support agents. Each session put the new flow beside the earlier process and compared the two on task time and the effort a request demanded of the person working it.

The walkthroughs shaped the flows shipped here. The baseline those comparisons were measured against, and the figure they produced, are not yet confirmed — so no percentage is published on this page.

08 — Architecture

One platform,
many systems

Three roles enter through one workspace. The platform holds the domains they share, reads its event and venue reference data from XMS, and talks outward to the systems a venue already runs on.

Channels & roles

Box Office
Customer Support
Venue Operations