Secure Event Ticketing using CiviCRM & Barcodes
Outline
A City of London based (not for profit) private members club had moved its member database from MS Access to CiviCRM in 2010. (see case study at http://edutech-insight.com/content/membership-management). The case study below discusses a project to provide a ticket issuing function for events and has been anonymised. The functionality described is only available to members of the Club and is behind a login.The primary goals for the initial Access to Civi programme were a) reduction of administrative costs – especially around renewals, and b) member data management to allow understanding of member behaviours individually and segmenting members against behaviours and attributes rather than the previous segmentation which was by membership type. The club offers a range of lectures and courses and some of these offer catering options where members can pre-book a meal as well as a place at the event. Following the move to CiviCRM Edutech Insight (EI) supported the organisation to begin to offer and manage its events using CiviEvent (and Drupal). Specification for this project revealed that the Club’s processes for marketing and managing events and for issuing tickets were very fragmented and that there were multiple process owners who were uncoordinated. The Club tried to address this but there was insufficient management will to change the majority of processes. This required EI to specify and design a number of ad hoc event purchase profiles and price sets rather than a coherent class of objects that could be reused. This had impact later in the programme. One of the other revelations of the business process analysis going into the events project was that the ticketing process for all types of events was wide open to fraud. Tickets for events were issued where the event title was not on the ticket let alone a unique ticket identity and/or series number. This revelation was sufficiently serious for the Club to agree to a project to use CiviCRM to produce and issue tickets for events that would eliminate the opportunity for fraud.
Developing the ticketing module
Because the Club’s events processes were so diverse and given the lack of management attention EI developed a specification which tried to envisage all the ways that tickets would eventually be issued. Tickets were to be available in real-time following an event booking in CiviCRM and would contain a unique id generated from the member’s CiviCRM ID, the event ID and the ‘seat number’. This would be produced as a barcode as it was intended that eventually, the ticket would be scanned and the information generated used to update a member’s event status with the information that they attended. Tickets would be delivered as a link to a pdf in the event confirmation email. The secretariat were to have access to all member tickets so that they could either re-email them or print them off and snail mail them to members as members might (and did!) lose tickets and some members did not have email addresses. Having specified the module, 3 UK companies were approached to develop the module. The work was won by Circle Interactive (CI) and was managed for them by David Moreton. CI produced the module based on earlier work by Hershel. The module was tested over a variety of circumstances and was accepted by EI on behalf of the Club.
Releasing the module
However, once the module was working in the production environment the Club decided that it was not ready with either its ticket collection processes or with member communications to introduce online ticketing immediately. There had resistance by a (vocal) minority of members even to online booking which had been available for 6 months and the Club’s management decided that it was necessary to give members 3 months prior warning that online ticketing would be introduced. The thought of 90 members turning up to an event where all of them had misunderstood that they should have printed their online ticket and had not done so promised more chaos than the Club was prepared to entertain. Meanwhile some members had been critical of the Civi process that required booking of multiple places at an event to be carried out ‘ticket by ticket’. There was significant confusion over the UI as when booking multiple places as the first place was booked, then the payment processor info was entered and only then were the additional places specified. Each profile required entry of both ticket type and dietary information for each participant. As a result of this feedback the Club’s events administrator decided that they would use the CiviContribute module and combination price sets allowing selection of ‘multiple place’ bookings as a single transaction with specification of the total number of each available dietary requirement in a single screen… However the ticket module had not been designed to accommodate this. The Club did not have the budget for a redesign of the ticket module. Circle Interactive generously adapted the module to work with CiviContribute and at least deliver a single ‘combination ticket’ with a field showing ‘No. of participants’. It was this ticket that was introduced following the three months’ notice to members. For the first event ALL the tickets that had been booked were printed off by the secretariat and held for those members who had not printed their own. About 20% of members attending the first event had not printed their tickets. 4 months on this number has fallen to around 5%. However about 10% of transactions still require telephone support with members either unable to find the link to their ticket in the confirmation email (various formats have been tried) or not having a copy of Acrobat installed and configured to display the ticket after they press the link.
Conclusions
This case history illustrates the problems that are, in our experience, relatively common with smaller not-for-profits moving to and using CiviCRM. The lack of consistent process, lack of management and changes in policy (where policy exists) mitigate against delivering much of the value that CiviCRM might otherwise deliver. Edutech Insight is not a developer. What we do is to try to help organisations to use CiviCRM to gain insight from the data they hold on their constituents such that they can provide better value for them and thereby increase membership/contribution/commitment and reduce churn. Organisations looking to deploy a CRM solution should realise that, in addition to selecting a technology solution they must also pay attention to their processes and management. CiviCRM is a fantastic tool and can provide excellent management support. But if management is lacking the value of the tool will be diluted. With this particular client the lack of management was not confined just to this project but was endemic across a number of Civi initiatives. Eventually this led to a summit with the senior leadership at which this paen (http://edutech-insight.com/sites/default/files/images/managing_with_civicrm.pdf) to systematisation was presented.
We hope this analysis might be useful to existing or potential users of CiviCRM and to other consultants struggling to help their clients understand exactly how they do what they do… Never the less out of this project a useful extension to Civi was produced.
Circle Interactive will eventually release the ticketing module sponsored by us and we both hope the community will find it a valuable addition to the available set of Civi tools. Watch this space!
-
Solution
This project was a functional extension to an existing CiviCRM installation.
Written with help from Chris Smith – Edutech Insight and David Moreton – Circle Interactive.