
Selecting Ticketing Systems
Selecting Ticketing Systems
By
Roger Tomlinson
Helen Dunnett
This guide on Selecting Ticketing Systems was updated in March 2018 from an earlier ADUK resource sheet first shared on CultureHive in 2012. Authored by Roger Tomlinson . Updated by Helen Dunnett.
Introduction
The systems are likely to have interfaces to accounting and other software solutions, and possibly an Application Programming Interface (API) to enable tools to be written to link to other databases and/or software solutions.
So, similar to cars, there are significant differences of detail between systems and what they do. But now how they do it and how they charge for it mean there are different models to choose from, and these can have significant implications for costs, control and flexibility.
System Types: Platforms, 'Software-As-A-Service', or 'Out-of-the-Box' Systems?
Just to confuse you, many of the technical terms are applied quite loosely, with imprecise definitions:
An already developed finished system that you purchase and install on your local servers. It usually comes with an up-front cost and then annual maintenance charges. The database is stand-alone and the data stored unique to your organisation and its customers. When the system is running, the data is on your local terminals and not dependent on external connectivity. It is usually the lowest cost solution, with your organisation taking responsibility for managing and hosting the system and its connectivity (PatronBase is one example of this).
The traditional 'out-of-the-box' ticketing system externally hosted in a professionally managed server farm - still your (or your system supplier owned) servers, but located in a secure supervised facility which ensures everything is connected, up-to-date and up and running. This will carry substantial monthly hosting charges (usually quoted per annum) but delivers technical peace of mind, though is reliant on external connectivity. You will be paying for the up-front purchase cost, the annual maintenance charges and the hosting as well as connectivity costs. Again PatronBase offers this example, with variants on how it is paid for.
Usually changes both the technical as well as the financial model. First of all you don't get your own system running on your own servers with its own database. Instead, most SaaS systems are "single iteration, multi-tenant" which means if there are 100 venues using the system they are sharing the one system and its database - it is possible for the database to be separated into compartments. Because every user is on the one system, there can be limitations on the range of functionality and local configuration. SaaS systems are externally hosted and only accessed over the Internet, with browser-based front-ends running on your local terminals. If connectivity fails, you have no access to the system. The supplier takes all responsibility for the system development, maintenance and up-time, and usually charges on some kind of pay-as-you-go basis (an example of this is Spektrix). There are few up-front costs except training, but recurring monthly usage costs for as long as you use the system, usually charged as a commission or per-ticket fee.
Sometimes called 'enterprise solutions', set out to take the best elements of the previous three approaches and deliver a platform on which an arts organisation can run modules of all the software solutions they need, on an integrated basis. The modules need not all come from the main supplier, but also be from approved third parties. The best example of this is Tessitura. There will be license fees for the basic elements of the platform, and then hosting and further pay-as-you-go charges for different modules. The cost can vary considerably between types and scales of organisation. In the case of Tessitura, your organisation is a co-owner of the network which gives you access to support and maintenance.
Cost Factors
Suppliers want to offer a competitive supply solution, but the challenge for some arts organisations is affording an appropriate cost-effective solution in the first place, since there are few inexpensive systems which actually offer all the necessary functionality required, and the annual costs of pay-as-you-go can become prohibitively expensive.
Variety of Cost Models
Additional Costs to Consider
Most suppliers charge separately from the up-front purchase or licensing cost for everything from project management, through installation and commissioning, to training, usually by the person per day, plus expenses. And watch out for additional costs for peripherals such as ticket printers, credit card and barcode readers, cash drawers if you want them, and additional software for rapid addressing, credit card processing, and so on.
However, we all know that most purchase decisions are not entirely rational and have strong emotional elements when choices are being made. Suppliers are run by people and the sales and support staff can be seen as a key part of their 'offer'. The choices other, and especially similar, venues have made can seem re-assuring and confidence building; there can be a pursuit of the latest, up-to-date, most current sales and marketing techniques enabled by systems; the look and feel of the software and the screens staff will be accessing all day long is a qualitative factor; and value-for-money perceptions can be skewed by many intangible factors.
Functionality and Fitness-for-Purpose
The variety of business procedures for selling tickets and running a ticket sales operation is remarkable. It is therefore very important to identify what you do and how you do it, in order to assure that the system will meet your current needs. You then need to identify what you would like it to do, to 'future-proof' your choice.
A quick over-view of systems can lead you to think that most systems do everything. However, there are significant differences in important areas. Some examples:
- Speed of Sale: For venues with a large number of events on sale, the method of drilling down into events/performances and the number of mouse clicks in a sale will be important factors – fewer, quicker being better.
- Packages and Subscriptions: For venues which have packages of events or subscriptions, how these are compiled, how they can be sold, especially rover or accumulator packages, how prices are set-up (calculation of percentage discounts), how they are renewed, will all be important factors.
- Membership and Loyalty Schemes: For organisations with membership and loyalty schemes, especially reward schemes, the options offered by systems will affect what you can do, especially redeeming loyalty points or membership benefits.
Database and Customer Records
Some systems come with their own proprietary database or effectively a closed database – this means the database is not necessarily 'open' – so it may not be easy to extract and or share data between databases in a standard format. Many suppliers will control access to their system's database. This is now important since many organisations 'interface' their software with other in-house systems and especially their website, and an open database such as SQL makes a significant difference. It also makes future migration between systems easier. One argument for platforms and 'enterprise solutions' is that data access and integration across modules is a pre-requisite.
Important Database Considerations
In the database, customer records are important, especially the available fields and their character, and what the system retains about their permissions and the consent procedures. Quick addressing, multiple phone numbers, email addresses, and data protection options for different communication methods, how notifications are made, how consent to sharing of data is obtained, are all very important.
Check how systems handle transactions from the web – some seem to create too many duplicate customer records when people buy on the web. Check to see if records at the same address – home or business – can be grouped together. Check how customer preferences and transaction history are separately recorded so you can understand interests and behaviours.
While the database is important for what it contains, the extracting and reporting mechanisms are crucial in enabling effective analysis and marketing. There are considerable variations in what systems do, beyond the basic ticket sales reports. Data extraction software is now available, which offers valuable data processing and direct marketing tools, and the ability to import and export the data. However, many organisations rely on the reports and tools inside their system, and it is important to be able to specify what you use at present and what you need (this is a key part of the Functionality Specification).
Internet Ticketing
Cost, functionality, and integration with websites are all involved here. Some system suppliers charge for tickets sold on the web by per ticket or per transaction fees; other suppliers offer the option of a one-off life-time license fee; others offer annual license fees, sometimes according to the volume of web sales. Most organisations will want to avoid per ticket fees and any add-on charges imposed on ticket purchasers.
Key Functionality Considerations
After cost, the crucial factor is ease of use and functionality for Internet ticket purchase: is this user-friendly with understandable, ergonomically laid out, screens and process flow? This can increase the volume of completed sales, especially by allowing purchasers to select their own seats. An effective Internet Ticketing engine is 'mission critical' for organisations now selling the majority of their tickets on the web.
What other functionality is offered on the web: a shopping basket; renewal of packages and subscriptions; purchase of memberships (with automatic pricing) and participation in loyalty schemes; sale of gift vouchers; purchase of food, drink, merchandise, use of promotional codes; editing of customer records and viewing of transaction history; payment by gift vouchers?
Integration and Compatibility
Most Internet Ticketing Engines are now incorporated by direct links into your own organisation's website. Just as your website needs to accommodate visitors using different devices, you need the engine web pages to accommodate different devices' form factors: traditionally pages were designed for desktop computers, but now need to adapt appropriately for laptop, tablet and smartphone formats - landscape and portrait - and to relate to ticket purchasers accordingly.
Significant Technical Factors
- Content management systems need to be compatible
- Are there xml feeds for websites or an Application Programming Interface?
- What (and when) are the registration and log-in options and how does it handle data protection requirements? Ideally, return customers should be recognised before they start making a repeat purchase
- How does e-marketing work in relation to the system?
- Are there social media interfaces and tools to integrate with other channels?
- How much can the website be configured to meet your needs?
- Are micro-sites possible according to customer types, or promotional codes?
Installation, Commissioning and On-going Support
The kind of training and support you need can limit your choice of systems. How knowledgeable are you and your staff about the business procedures for ticket sales? This could significantly affect costs and be very demanding during the commissioning phase. Systems offer many options and alternatives and during set-up and configuration you will be asked many questions about your detailed operational requirements, with many crucial decisions to be made.
With open database systems, the application of what you want to do with the system, and others it can interface with, is very important. Suppliers offer specialist staff to assist you, but they do not always understand your business requirements in detail. This is equally important when you and your staff are first being trained.
Support Models
On-going training and support can be make or break for most venues in their successful use of the system. However, both training and support is changing on both the basis on which it is supplied and how it is charged for. Some suppliers operate on the basis that they will not provide 'attended support' – so you will only ever be visited on site at the time of initial training and commissioning. That said this is changing and many suppliers understand how important it is to keep staff up to date on functionality and use of the system by providing annual (sometimes more regular) onsite visits.
Strictly, most suppliers of ticketing and marketing systems supply 'software support' and any support requirements for hardware, peripherals and connectivity needs to be sourced separately (and if possible, locally). This is very different from some of the long established suppliers who, traditionally, have offered a 'one-stop-shop'; such practices have largely ceased.
The Selection Process
Most organisations do not know what they could have at the start of the selection process.
Find out what is on offer in the marketplace. Most suppliers will be either willing to visit to provide a demonstration or offer a web presentation to show what they think their system is best at. Some arts and entertainment organisations invite a number suppliers down to deliver a series of presentations to their staff team on one day, to help familiarise with the available alternative solutions. These are sometimes called 'beauty contests' but the key point is that they inform about what is available, help staff understand the state-of-the-art, and build consensus about what a venue might need. This is best achieved by seeing at least three systems.
Identify what other arts organisations are doing and seek comparators to discuss their experiences with systems. This may provide 'references' on systems but is not always helpful since experiences can be very specific to an organisation and their circumstances. One venue can be removing a system in disappointment when another is installing it as a carefully selected 'fit-for-purpose' solution.
Develop a 'Functionality Specification', which describes what your organisation wants the system to do. This needs careful thought. It is important not to describe exactly how a system might process something (though for some tasks this may be unavoidable) but instead to describe the objective and outcome. Different systems can achieve the same outcome in different ways. A key part of the Functionality Specification needs to be about reports, data extractions and data processing.
Most organisations, especially charities and local authorities, are required to seek tenders on the MEAT principle from at least three suppliers for systems. It is appropriate to prepare a briefing document about your organisation and the venue(s) quoting volume and value of tickets sold, number of performances, size of venue(s) and variations in seating layouts. This document should include details of the number of customer records on the system and the period going back for which transaction records will be migrated.
The briefing should specify a timeline including:
- The date and time tenders are to be received and in what form
- The date of short-listing being completed
- The date for evaluation sessions
- The date the 'project' is to start
- The date installation and commissioning is proposed to start
- The date training for staff is proposed to start
- The date of any 'live' data migration
- The date for 'go-live' of ticket sales on the new system
It is usual to ask suppliers to score their response to each point on the Functionality Specification on a five point scale:
Having scored the responses, it is useful to compile a comparative spreadsheet of the costs. For the MEAT principle, it is recommended to calculate a comparison of the five year cost of ownership.
Compile a short-list of those systems you wish to evaluate in detail. These ought to be only ones you are genuinely likely to select. It could be perfectly reasonable that this is only one system now, or perhaps two and at most three. By now you should know what you want and what can meet your needs.
This is not a further demonstration, but ideally a step by step working through of the Functionality Specification on a WYSIWYG (What You See Is What You Get) basis. This can easily take a whole day and should not be rushed. Some suppliers offer 'analysis workshops', at a cost, as a pre-contract stage to formalise and agree exactly what will be supplied and any specific development needs.
The negotiation of the contract is not always straightforward and many arts organisations become exercised by the degree to which the system suppliers seek to evade all responsibility. Unfortunately, money can be wasted on lawyers when the suppliers are simply unwilling to negotiate their standard terms. Do not expect them to accept open liability for system failure or down-time and they are unlikely to guarantee support response and fix times.
