This was never a dashboard problem
Customers buying premium sports travel commit thousands of dollars six to nine months ahead of the event. In the gap between purchase and arrival, the only artifact they hold is the portal. It listed what was charged. It never listed what was included.
The business felt that in three places, in this order:
- Customer confusion. No access to hotel, transportation, or event logistics detail — the things people actually bought.
- Support overload. Agents spent their day answering questions the product should have answered. Every ticket was a design failure with a payroll cost attached.
- Retention risk. A weak post-purchase window produced negative reviews and suppressed repeat purchase, in a category that runs on repeat purchase.
The reframe that made it solvable
Someone who books in November genuinely cannot recall what they bought by the time March arrives. That is not a failure of attention, it is how nine months works. The portal's job is to remember on the customer's behalf.
Once the brief was memory rather than reporting, the screen designed itself. The order view got reorganized around the experience purchased instead of the transaction recorded: package contents, hotel, transport, and event logistics surfaced together, in one place, in the language of the trip rather than the language of the invoice.
What shipped
Two months, desktop and mobile, in production for the full customer base.
- An order view built around what was purchased, not what was billed
- A 4+ click path to core trip information collapsed into a single screen
- A payment-progress surface for multi-installment orders — a $50,000 booking paid in halves needs to show state, not just a balance
- The design system underneath: components, tokens, and patterns built to carry the next property, not just this page
Why the numbers moved
Ticket categories were the design brief. “What’s included?” was not a support problem to staff around, it was a specification for a screen that did not exist yet.
Designing against the actual volume of inbound questions is the only reason the results are measurable at all. The baseline was already being recorded in the support queue. Nobody had read it as design input.
What the business got besides the percentages
The ticket reduction is the headline, but it is not the whole purchase. Four second-order results outlasted the engagement:
- Support and sales redeployed off repetitive questions and onto complex, revenue-bearing ones
- A design system that shortened every subsequent site deployment
- A cross-functional working model between design, support, and engineering that survived the project
- UX repositioned internally as a revenue-enabling function rather than a cost center
What another two months would buy
Instrument the portal the way the support queue was instrumented, so the next round of decisions comes from behavior rather than from tickets. Then extend the system sideways: the same order-view patterns carry to the other properties on the platform with configuration, not a redesign.