WAM Tickets – a complete ticketing system

Morgan Strong's blog | Created 4 years ago

In mid-2012, I wrote a piece about the technical infrastructure that underpinned our ticketing solution that we had developed for the Erth Dinosaur performances. This solution was designed for performance based exhibitions, and as stated in my blog, integrated beautifully into our Drupal / CiviCRM environment.

However, in late 2012, we faced a significant challenge to extend this system to run exhibition ticketing for our next two blockbuster exhibitions: Unveiled and Secrets of the Afterlife. Unlike Erth, which had finite times, capacity and mostly online ticket sales, these exhibitions required the development of a POS interface; a much heavier focus real-time information sharing between different booking areas (front desk, education, online, booking line and administration); and specific mobile apps to help monitor the exhibition.

So with these new requirements at hand, we got to work on redeveloping and extending WAM Tickets to meet these new challenges.

Like the first iteration of the ticketing system, the reasons for continuing inhouse development were compelling – we could keep costs extremely low, control every element to manage crowds and numbers, develop accurate reporting tools, and offer customised workflows for the relevant departments. There were other ticketing solutions out there, but nothing that could match our workflows at a reasonable price.

The downside inhouse development was deploying an accelerated project development timeframe: the Erth performances finished in mid-October 2012, and we had two weeks to refit the online system, and then four weeks after that to have all the Point-of-Sales (POS) and ticket booths ready for the launch of Unveiled at the start of December 2012.

So there was no time to waste.

As a outlined in my previous blog, we’d already developed integration between CiviCRM (performing events management) and a Drupal booking system, and we’d made a little mobile web app for scanning tickets and feeding back information to staff on the door, so this package (let’s call it WAM Tickets 1.0) was the natural place to start extending.

First port-of-call was to develop contingencies should everything turn bad (say the ticket machines all failed, or printers broke etc), so we modified the barcode validation script to allow a certain sequence of barcode numbers to scan in for “any” event, rather then the session-specific events we were selling at the door and online. Once the validation script was successfully modified we reserved some barcode sequences and printed off several thousand and kept these in a safe place for sales should the worse happen.

This logic turned out to be quite useful as we were able to use this to generate gift tickets and complimentary tickets, as both this ticket types needed to be session agnostic.

Secondly, we got to work on developing a UI (user interface) for physical ticket sales. We decided the most efficient method was to develop a custom UI for CiviCRM which stripped back all the features except events management, then made some webforms to sit on top of the application. This turned out to be quite a bit harder then we’d hoped as we needed to write huge amounts of Javascript to override default system behaviours and to auto-populate the forms’ default settings.

CIVICRM registration page with the WAM POS Booking user interface

Registration Page
Image copyright WA Museum 

We needed to provide many features in this POS UI, including: ability to select any session (not just the current one); inspect how many tickets had already been sold to ensure an event was not oversold; generate specific workflows for credit card or cash sales (or a blend of the two); collect postal codes against ticket types; and very importantly, be fast enough to ensure the queue keeps moving.

POS booking user interface showing events and availability

POS Booking
Image copyright WA Museum 

We persisted through the requirements and the libraries of Javascript to power the workflows after a few weeks, we had the necessary UIs ready to roll, which led to the next component: ticket printing.

For Unveiled we used a simple thermal printer and placed a nice design at the top of the receipt, the transaction description / tax invoice in the middle, then the barcode at the bottom. Quite a bit of work went into optimising the print templates so we could print direct from Chrome and run the entire process as a web application, but overall this was a relatively simple process.  

After developing the ticket printing component, we had contingencies in place, online sales running, a POS for physical sales, ticket printing from the web application, and we retained the scanning process developed for WAM Tickets 1.0. This robust ticketing package was ready for deployment (we’ll call this one WAM Tickets 2.0) and it was used effectively throughout Unveiled, which ran until April 2013.

However, our next blockbuster exhibition, Secrets of the Afterlife, was due to start in May 2013, which left us with another six-week window to add a bunch of new features to help manage this new, bigger exhibition.

First and foremost, we decided to use a more sophisticated ticket printer (BOCA printers) and used pre-printed, themed ‘concert style’ tickets. Using these printers and ticket stock required much more customisation. For example, we had to ensure the correct number of tickets printed (eg. 2 X adult entry would print two tickets, but a 4-adult group printed one ticket). We also improved the barcode generating script to encode more information and optimise its printing on the new ticket stock. But the most challenging process was the fine tweaking of the print area and print buffers to ensure the entire rolls of tickets printed correctly. Perfecting this ticket printing process from Chrome was time-consuming, but an important step as it meant the whole ticketing system operated as a web application.

Another additional process that was developed for Secrets of the Afterlife was an education bookings management component. This was a similar UI to what was developed for the POS, but specifically built around school bookings, including tentative bookings, automatic emails dependent on workflow, and of course, real time synchronisation with the POS and online ticketing system to ensure a smooth flow of visitors.

Education booking user interface showing events and booked schools

EDU Booking
Image copyright WA Museum 

Lastly, we wanted mobile reporting for the executive and directors – so we wrote a simple web app that would allow directors to log in and check how ticket sales were going in real time for particular sessions, inspect advanced sales for future events, and also browse overall exhibition performance. In comparison to the other tasks, this was a walk in the park, and it gave significant control to managers, as they did not have to wait for ticket reports on sales and knew in real time what was happening on floor.

And at the conclusion of this, we have the current generation of WAM Ticketing (let’s call this one WAM Tickets 3.0), which should be pretty much able to handle any new exhibition (held at the metropolitan museum site) that we throw at it.

The next iteration will be making a smaller, mobile version of the ticketing system that will be able to be used at our regional locations when they hold paid exhibitions. Stay tuned in 2014 for the next blog post about developing this product.