Ticketing 2017: Two New Projects Take on Complex Challenges

Editor's Notes

• #3: Douglas: Good morning. My name is Douglas Hegley, I’m the Chief Digital Officer at Mia. Part of my responsibility is to ensure that our customers are happy. One of the experiences where we have struggled over the years has been online ticketing. During our short presentation this morning, we are going to focus on just that. <see bullet points>
• #4: Douglas: I realize I’m generalizing here, but the bottom line is that we have provided an unsatisfactory user experience. And now as we enter an era in which data collection is going to be scrutinized as never before, are we actually *preventing* our own success?
• #5: Douglas: Ultimately, can’t we just make the thing better? Today we will share some information about two approaches taken to improve the situation. We hope that what we share is meaningful and useful to colleagues across organizational levels and responsibilities.
• #6: Douglas - Due to time constraints, we’ll be limited to a high-level overview of our paper that has been published in the proceedings of this conference. In a moment, I’ll step aside and let the real experts tell you more about their projects and how they were accomplished. At Mia, we were unhappy with our system, we scanned the competitive marketplace, and frankly we still were not happy, What to do? Build it ourselves! <buy vs. build> High level overview (promise to share the deck)
• #7: Andrew S “All the things you can now access on your phone” We’ve used TNEW since late 2011 Put a lot of work into improving look and feel, but very difficult to affect the overall UX Web redevelopment project in 2016 Purchase path should be easy, like buying a ticket in person To see through the user journey, decided to build our own product
• #8: Andrew S We decided to build our own product “Museum Nice & Simple Ticketing”, or MNST for short. Nearly no budget, just a small external code review before launch The infrequent nature of buying tickets means that the password reset page was used by nearly all users.
• #9: Kjell Olsen Simple process to browse and select tickets Slightly different steps required for different types of ticket events/Lectures are straightforward Exhibition / tours require a selected date Some events require special info - lunch selection, name, other info Discounts apply according to membership information Checkout sends the order to API, which handles payment and data
• #10: Andrew S Essentially a middleware for Tessitura API calls 3 step transaction process Select tickets Confirm and enter payment details Get a receipt Large, touch-friendly buttons, mobile-first design Add on items and top up donations No option to log in, no passwords to remember or reset, reduce distractions and cognitive load of buying a ticket Existing accounts are matched by e-mail address, otherwise one is created Most modern browsers remember auto-complete fields - much quicker than resetting / forgetting password Pricing rules are all handled by Tessitura E-tickets are sent via Tessitura’s existing print at home ticketing service.
• #11: Kjell Olsen - describe (briefly) the choice of React and why it’s effective. React - a simple abstraction to write complex behaviors Note: no delusions - this is hard stuff, and maybe we were not fully aware of how complex this was going to be. But we are selling tickets!
• #12: Andrew S Nine months from prototype to beta launch Smallest scope possible MNST built to progressively replace to TNEW Links on website constructed from URL + performance ID Loose coupling between website and ticketing site Tessitura is persistent datastore MNST contains no data of its own, can be destroyed and rebuilt Deploy / rollback provided by feature flag in CMS, switches URLs Tech stack: Python and Flask Flask allows simple request, function, response workflow
• #13: Andrew David, Misty Havens June 2017 with August 2017 Launch MVP was to sell exhibition tickets, membershipConnect to SF data to allow for membership entitlements and record new members Since August we have been: refining data from massive migration refining the cart logic and error handling Setting up reporting Designing and building a CMS for Hive With much more to come!
• #14: Andrew S Loose approach to roadmap items, and features come and go from development cycles. We know long-term that we’ll want to do packages and passes for film festivals. We’d love to find an appropriate way to share what we’ve made with the community, but: Open sourcing things involving closed-source products can be difficult (Tessitura), and there are considerations when it comes to PCI and risk. The most valuable part of the process (for us) was getting to a place where we can do iterative development for online ticketing. Complexity beneath simple interfaces is often obscured Breaking down features into individual issues was challenging, so... If anyone else wants to have a chat about building this sort of thing in-house, do get in touch!
• #15: Andrew David