Should multi-venue groups centralise ticketing?
Multi-venue groups should centralise ticketing functions that benefit from shared standards, customer journeys and oversight, while retaining local control where venues have distinct commercial, operational or legal requirements. A central platform can reduce duplicated systems and make group reporting easier. It can also create new dependencies and governance problems if every venue is forced into the same processes.
The decision is not simply one platform versus many. Groups can centralise technology, customer accounts, procurement or reporting in different combinations, and those choices have different consequences.
What does centralised ticketing actually mean?
Centralised ticketing means that multiple venues use some common technology, data or management processes instead of operating entirely independent services. Centralisation can take several forms.
The most centralised model is not automatically the best. An organisation with wholly owned venues may have more freedom to align data and policies than a consortium of independently owned theatres.
What benefits can centralisation deliver?
The strongest benefits come from removing repeated work and making the same information usable across locations. For example, shared event templates and consistent reporting fields can reduce routine setup and consolidation effort. A common customer account may let patrons find tickets for several venues in one place, subject to the group’s privacy and identity arrangements.
Central procurement or a shared contract may also simplify support and technology governance. Rather than maintaining several unrelated integrations, the organisation can standardise certain connections to CRM, analytics or finance systems. A central support team may spot recurrent payment problems or seasonal demand patterns that would be invisible in a single venue’s dashboard.
These benefits are conditional. They depend on reliable data quality, practical permission controls and staff adoption—not merely changing the supplier logo.
When is local autonomy the better choice?
Local autonomy is valuable when venues differ in ownership, operating requirements or commercial accountability. One theatre may depend on membership and donations, while a live-music venue prioritises general admission and promoter allocations. An attraction might require timed entry. Different countries or legal entities can also have different payment, tax, privacy and consumer requirements.
If a common system cannot accommodate these differences, centralisation may lead staff to invent manual workarounds or maintain shadow spreadsheets. That raises rather than reduces operating risk.
A group may also decide against sharing identifiable customer records. A consolidated view of attendance or revenue can sometimes be produced from appropriately aggregated, permissioned data without merging every person’s purchase history.
How should the group weigh the commercial trade-offs?
Compare the full operating cost of each model against the expected benefits, not just software subscription fees. A shared platform may reduce licences, integrations and duplicated support. It may require substantial migration, retraining, contract amendments and ongoing central governance.
For illustration, suppose a group has five venues paying £18,000 each per year for separate ticketing systems. That is £90,000 before integration and support costs. A consolidated alternative with a £65,000 annual platform charge is not necessarily £25,000 cheaper. Implementation, payment fees, seat-map work, retained local tools, staffing and transition costs may change the comparison considerably. The numbers are hypothetical, not market benchmarks.
Revenue effects matter too. A unified checkout could reduce friction for repeat customers, while removing a venue-specific workflow could harm conversion or membership fulfilment. Test those propositions rather than assuming either outcome.
What needs to be decided about customer data and identity?
Before centralising customer records, determine who is responsible for the data and who may use it for each purpose. A central CRM record, group-wide login and shared marketing permission are three different concepts.
A buyer at Venue A may need to sign into Venue B using one identity while still receiving venue-specific communications. In a group of separate legal entities, data-sharing arrangements may be necessary; access should be scoped to authorised purposes and retention requirements. The fact that a platform technically supports cross-venue data doesn’t itself establish a lawful right to use it.
Tessitura’s publicly described consortium model illustrates a relevant distinction: organisations can share ticketing capabilities while restricting each institution’s private records and keeping separate accounting arrangements.
How should central and local responsibilities be divided?
An effective centralisation model assigns ownership for shared rules and venue exceptions before launch. The group might standardise platform configuration, security, data definitions and supplier management while leaving event programming, seat holds, local fulfilment and frontline customer care with venue teams.
A practical responsibility matrix should say who may create events, publish onsales, change prices, authorise refunds, release held stock, export data and respond to incidents. It should also identify who approves changes affecting more than one venue.
The question is not how many tasks can be moved to headquarters. It is which tasks benefit from consistency and which rely on local knowledge to avoid delays or mistakes.
How can a group decide without committing to a full migration?
Use a representative pilot to test both shared benefits and local exceptions. Choose two venues with clearly different workflows, such as a reserved-seating theatre and a timed-entry attraction. Test their public booking journeys, payments, permissions, support and reporting.
Agree measurable success criteria before the pilot: fewer manual reconciliations, shorter event setup time, fewer duplicate customer records where lawful, better group visibility or reduced integration maintenance. Include failure cases such as a venue-specific refund rule or a staff permission conflict.
A hybrid approach is often a sensible transition. The group can first standardise reporting, account access or integrations, then assess whether full platform consolidation remains justified. Centralise what must be shared; preserve what genuinely needs to be different.