Redesigning the Rival Labs Reporting Suite
Skills Developed:
Table design / report implementation / first principles approach / detailed spec writing / sprint planning
Time:
Jan 2020 - Apr 2020
*Mock of the original reporting suite. I’m unable to show many screenshots due to the proprietary nature of the platform.
Background
I joined tech startup, Rival Labs Inc. (acquired by LYN in 2020) in May 2019. Headed by former Ticketmaster CEO, Nathan Hubbard, Rival built a next-generation enterprise platform and white-label consumer app built to power live events for major venues and sports teams across the country and abroad. The enterprise platform allows organizations to easily configure, sell, manage, scan and report on large-scale events. One of the projects I was lucky to own there was the redesign of our suite of reporting tools. This is a brief outline of the process I underwent in doing that.
Having worked as a user on several ticketing enterprise platforms in the past, including Ticketmaster, AXS, and Outbox, I was highly familiar with the types of use cases and functionality necessary for the platform we were building. That subject matter expertise, along with many conversations with our clients was tremendously helpful in identifying user needs and goals throughout the process.
Initially, our reporting suite was designed with an explicitly transitional mindset. Understanding that our planned launch partner was accustomed to running reports on a different ticketing system, we developed our reports to prefer consistency with legacy reporting over more natural expressions of the capabilities and state of the Rival platform. As this operational continuity became less important, and our functionality expanded, it was necessary to begin developing a new approach consistent with the platform’s capabilities.
I collaborated with the Director of Product on this project as he played a key role in designing the original selection of reports and was a helpful source of feedback throughout.
Ideation
Outlining Goals
We began by defining the library of reports based on categories of purpose: Event Configuration, Sales, Operational, and Financial. We established a set of reports within each category to address the key set of use cases we needed to address. Some of these required refreshing existing legacy reports, while others needed to be designed from scratch as they expressed functionality unique to our platform.
Establishing Design Approach
For the MVP version, we preferred to keep all reports in static tabular format, as the most important goal was expanding data visibility for users and presenting it clearly and accurately. A more graphical dashboard approach would come later.
To unify reports and make them more consistent to generate and use, we defined detailed global standards for headers, file types, and style formats. The UX team had little work to do as the reporting interface and report generation flow largely stayed the same. Most of the updates were implemented by our BE engineering team.
The Event Inventory report describes the inventory structure and basic configuration for an event (price tier, inventory category, inventory status). This was a refresh of a legacy report that provided information on the current status of seating inventory in list format. For instance, the user needs a list of all seating inventory currently allocated for TALENT use. In the new version, I wanted to expand on this by adding Rival-specific properties, such as Distribution Status, Ownership Status distribution assignments. I also introduced a ‘Roll-up Mode’ so that groups inventory could be included on a single line, rather than 1 seat per row for an easier to read format. The result is that users could access additional information from the report that was abstracted away in the previous iteration, such as what actions could be taken on seats based on their state, and what offerings had access to them.
Event Sales Report:
Of the legacy reports that required a reconfiguration, the Event Sales report perhaps required the most scrutiny. The report this replaced is commonly referred to as the Event Audit, and is by far the most widely used industry standard for describing potential and realized sellthrough and revenue for an event. To change this drastically, would create difficult buy-in from venues and promoters that have for many years relied on a commonly understood format for relaying and discussing this information. For this reason, it was important to find a balance between entrenched formats and new, more useful expressions. To do this, I explored a wide variety of use cases separated by four key categories of information: Price Configuration, Sold Inventory, Revenue, and Unsold Inventory.
After deliberating use cases with the Product Director, I was able to ensure an approach not dependent on my own experience bias.
I tried out several iterations in the spec before landing on one that worked well. The final product resembled the column/row format from the original report, but included several additional features, parameters, and data points useful to the user. Notably:
- Sales by Category table: A table allowing users to view sellthrough totals based on the allocation category of the inventory. This is impossible in other systems due to the inseparable nature of ‘category’ and ‘ownership’;
- Carted by Category table: The same as above, but for inventory currently reserved that has not yet been transacted.
- Sellthrough percentage row: The percentage value of the amount of sold inventory in a given Price Tier out of the total inventory in the ‘Available’ Distribution Status in that Price Tier (Sold / (Sold + ‘Available’ Unsold)). The comparable data point was included for the Sales by Category table.
- Flagged inventory row: The amount of entitlements in each price tier that are in a ‘Killed’ Distribution Status, reflecting a conflict that may be reviewed by the user.
To give longer term direction on the future implementations of the report I included a prospective ‘Future Work’ section in my documentation:
Payment Allocation Report:
The Payment Allocation report is an example of an entirely new report meant to fill in gaps left by the legacy reports implemented in the initial push to launch. In particular, the Payment Allocations report replaced two legacy reports known as the Method of Payment and Payment Distribution reports.
The purpose of the Payment Allocation report was to support our client organizations’ finance/treasury groups to understand how payments processed through the Rival platform are allocated by form of payment to inventory and surcharges so that those payments can be properly reconciled in the organization’s financial reports.
The key requirement was to describe the value of payments that have been ‘matched’ against the different kinds of inventory within an event, or different surcharges within a product. These payment values are broken down by form of payment. Additionally, this report could be used to describe the value of payments within the system that is not currently matched to an order at all for the purpose of tracking prepayments or other unearned revenue. This concept of payment matching is a feature the Rival team developed to overcome many of the pain points users encounter in tracking and reconciling payments in other systems.
Engineering Team Deliberation
In each case, I convened with my engineering team to talk over the report spec, clarifying aspects of the expected behavior and addressing any implementation concerns.
Iteration
- [P0]
- SPIKE:Write SQL query to generate report
- See what fields needs to be added to the intermediate data store [BE]
- [P1]:
- Per the above, add the new fields to intermediate data store [BE]
- [P2]:
- Implement API to generate report [BE]
Final Thoughts
Given time, I would have liked to incorporate a more graphic dashboard with visuals elements and more interactive representations. Still, I’m glad to have been a part of changing how these reports work in an industry where old representations are so entrenched. And for me personally, it was a great exercise in exploring tables and how to cleanly and represent data to users, while also navigating some of the complexities around database storage.