CASE STUDY | EventBase

While newer applications like the Event Management Tool (EMT) offered improved usability, they were developed in isolation, resulting in a lack of consistency and interoperability. Furthermore, essential event creation and management tasks remained out of reach for clients, as these tools were internal-facing and accessible only to Ticketmaster support.

When I started at Ticketmaster, there was no formal design research being done and designers were not allowed access to clients (the users of the software they were tasked with designing). This had to change. We worked with our internal partners in Product and Support to help them understand the vital role of design. We included them in our process, soliciting their input at each step and relying on their connections to establish relationships with trusted clients. Most had never participated in the development of the products they relied on every day, and were thrilled to be asked to share their knowledge and experiences.

Event venues are high-pressure environments, particularly during peak sales windows and immediately before showtime. To ensure our solutions fit this reality, we conducted on-site field research at venues of all sizes. By observing box office and back-office operations firsthand, we engaged with stakeholders across the entire live event ecosystem—from artists and promoters to venue managers and front-line staff.

We facilitated journey mapping sessions with a diverse cross-section of users. These sessions revealed a critical insight: while clients performed similar high-level tasks, their specific workflows, environments, and customer bases varied significantly. This discovery drove us to pivot from a 'one-size-fits-all' strategy to a flexible product suite tailored to distinct operational needs.

This strategic shift aligned with the organization's broader transition to an Agile development framework.

Ticketmaster has built many tools for its clients over the years. Some utilize dumb terminals, some only run on Windows®, and many of the newer tools are Web-based - but they each had their own URL with no centralized access or user accounts, and no ability to share data. Clients had to maintain multiple accounts - one for each tool - and there was no easy way to continue their work across products.

The first thing we did was gather up all the products our clients were already using into a single domain for easier access (and enhanced discovery - many clients didn't know what tools were available). This also allowed our clients to create a single identity, with one set of credentials, that could be maintained across products seamlessly, requiring only a single sign-on per session. The product, called Ticketmaster One, was little more than a portal at this phase but it was a critical first step.

Early Publish

The first thing clients need to do is notify Ticketmaster of the intent to stage an event by submitting some basic information, which also creates a web page where fans can go to learn about the event and eventually purchase tickets. We called this Early Publish, and it was an extremely thin slice of functionality from the massive (and massively complex) Event Management Tool.

One of the biggest pain points for clients was called Scaling - the process of setting base ticket prices for an event. It's a complicated and tedious task when done entirely by hand, and was an age-old problem in need of a modern solution. Enter Scaling Sandbox. In a nutshell, Scaling Sandbox allowed clients (typically promoters) to easily select the seats they wish to sell for a particular event on an interactive seat map (ISM), and test out different pricing scenarios to determine how best to meet their revenue goals.

With no products capable of picking up where Scaling Sandbox left off, the data itself was largely trapped within the tool (this is where the "sandbox" part of the name came from). Still, it was a quantum leap over paper-based scaling.

The companion activity to setting base ticket prices is determining which seats in a venue will be sold for a particular event and when they will be available. This is a dynamic activity, with inventory being reallocated throughout the event life cycle. Inventory Control provided a way for clients to see the current status of their inventory, and make requests to change that status (from "hold" to "open" for example). While, for now, the changes had to be executed by Ticketmaster support staff, with Inventory Control those requests could be submitted, tracked, and reviewed more efficiently.

Scaling & Inventory

The two primary map-based operations are Inventory and Scaling, which until now were handled by two separate applications. We first combined them onto the same interactive seat map (ISM), but there was more work to be done as each tool lacked some key features. For example, the pricing information developed in the Scaling tool could not be saved directly to the manifest, which is the database of seats in a venue which can be sold for a particular event; it had to be input, by Ticketmaster support, in a separate step using the data manually exported - on paper - from Scaling as a guide. We fixed that so that scaling data was saved directly to the inventory database as soon as clients were satisfied with the results. 

The capability to submit and track inventory change requests was useful, but without the ability to update a seat's status directly clients were unable to respond quickly to market conditions - like releasing reserve inventory when a popular event is close to selling out. With EventBase’s capabilities, clients can instantly change any seat's status without an assist from Ticketmaster.

Floor Edit

While most of the seats in a venue are fixed in place, arenas almost always have different floor seat configurations for every event, requiring a unique ISM for scaling and inventory. Previously this meant submitting floor layout specifications to the Ticketmaster maps team and waiting for them to build a new ISM before a client could even begin pricing an event. To address this we created Floor Edit, which allows clients to customize an existing ISM, assembling their own floor seat layout using the event’s specs, rather than waiting for a new one to be built. 

ISM Improvements

At one time, there were three different ISM technologies in use across Ticketmaster's products, including one that couldn't handle venues of more than a few thousand seats and another that was entirely dependent upon Flash (yep, Flash). None were usable on mobile devices. Enter SuperMap: a new ISM tech built on a modular, modern stack that loaded quickly and rendered more crisply than previous versions, was fully responsive down to mobile, and could handle the largest venues supported by Ticketmaster. By upgrading the underlying tech of the ISM and making it plug-and-play, we were able to design a ton of useful enhancements and deploy them easily across all products with an ISM.

Whether your venue hold 100 fans or 100,000, you can't sell a single seat without an offer. At the time offers could only be generated by Ticketmaster support staff, a potential bottleneck. Giving clients the ability to create offers themselves meant they could immediately assign inventory and start selling tickets without waiting on Ticketmaster. This also allowed clients to update offers on-the-fly, which is critical during busy sale periods when they need to react quickly to the market.

With so many different personas involved in the event creation process, the benefits of collaboration were clear, as was the need to effectively facilitate it. Once we had an understanding of the ways our clients worked - and worked together - we designed a full set of collaboration tools and sequenced their release to gain the most bang for our buck. Flexible permissions, in-app sharing, direct messaging, tracked commenting, and versioning of multiple scenarios were the first to come. 

Some of the most intense collaboration takes place during the scaling phase when promoters, artists, and box office managers pass different pricing scenarios between them in pursuit of their revenue goals. We created an in-app messaging and notification system and tasked our SuperMaps team with implementing WebSockets to allow live, simultaneous editing on the ISM (interactive seat map). Clients could also solicit and track approvals from key stakeholders at various stages without having to use external tools - like emailing PDFs or Excel files and then waiting for a reply, making changes, and repeating the process over again.

In addition to the work on our products, we also conducted a major brand evaluation and redesign exercise for all of Ticketmaster which we used to inform our design system, codenamed Aurora. This system covered not just our enterprise products, but all touchpoints of the Ticketmaster brand, including consumer products and all marketing & communications throughout the organization. It was a massive undertaking, worthy of its own case study.

By now, the major features needed to create and manage events were in place so we shifted focus to implementing our updated design language (Aurora) and integrating EventBase more tightly with other apps in the Ticketmaster ecosystem, including Reports and Marketing which were often used by the same folks who built the events. We also introduced truly responsive layouts, down to mobile (even enabling simple operations on an Apple Watch for the hell of it).

In addition to the integration work and responsive layouts, we implemented a portable data structure that could be surfaced across different apps, system-wide notifications, and a comprehensive in-product help service that integrated directly with Salesforce which was already used by Ticketmaster support staff.

While all of those efforts continued, we began working on the next step in our product evolution: a single application experience that incorporated all of our enterprise capabilities in a single app called TM1. In addition to unifying all of our tools, TM1 introduced an array of new features including support for tours and runs, custom dashboards, universal search, granular pricing tools, and automated inventory control. 

Some examples of these features are included in the Products section.