For the recent Erth Dinosaur performances, the WA Museum decided that we should internally manage booking for the events, and build our own custom ticketing system that would feed information back to our website and CRM.
This blog post will give you a high-level view of how we did this and give a few pieces of advice for those wanting to do the same.
The first step was to create all the events in CiviCRM and then link the registration pages to event listings on the website. Easy. However, this is not a ticketing solution as there are missing gaps, such as unique ticket referencing, ticketing emails, physical ticket management, generating event run sheets, et cetera, et cetera.
So we started by deploying the Drupal Barcode module so that it would generate unique barcodes for each ticket sold. To make a valid number on the barcode, we used a formula based on the event registrant ID and the event ID and then applied this formula to generate a unique barcode reference. We then modified the event receipts in CiviCRM so that they would contain this barcode in the receipt email, as well as generate a PDF copy of the ticket upon successful event registration.
We now needed a suitable payment gateway that would integrate into CiviCRM, so that we could take payments, and also build participant and event income reports through CiviCRM. The Museum already had MIGS as a gateway for the online store, but we were looking for a streamlined processor that would sit on top of this.
CASConnect were contacted, and they went about building a Payment Processor for CiviCRM which worked perfectly for our needs.
The finance, events management and receipt generation side was now completed. We now had to look at the physical processing of the tickets on the door.
Next we set up acquiring some simple barcode readers that would plug into an iPad. We then created a few scripts that would take the scanned barcode information and then update the registrant information in the CRM with their status, and then feedback that status information back to the iPad (paid; pending payment; already scanned; wrong event etc).
We went to quite a bit of work optimizing the messages, so that only a few KBs of information went back and forward. We were relying on a 3G hotspot to transmit data, and the Museum building had many thick walls that blocked reception. So small packets of data and fast responses with the server were hugely important.
We now had the scanning activity updating the CRM participant status. But the next step was to make sure that the view on the iPad was simple to use, and at a glance could feed back the required information to staff scanning the tickets. There would be around 350 people rapidly moving into the room at the start of each performance, so rapid responses were at a premium. Thus we made a custom view that pushed the barcode ID back to the iPad, which then displayed a very large icon describing the ticket status.
Lastly, we made a view of the event run sheet. This view contained a list of all participants with the relevant barcode next to their name, as well as the number of registered participants under that ticket. The run sheet could be printed just before the event and contained a full list of all registered participants so that anyone who had printer troubles, forgot their ticket, or didn’t realize they need to print their ticket, could present photo identification and we could scan the barcode off the run sheet.
Voila! A custom ticketing system that integrates into our CRM, works for our requirements, and saves us considerable money.