festival.productions

Guide · Ticket sales

Choosing the right ticketing system for your festival.

Your festival lives or dies by ticket sales, and the ticketing system you choose determines how much of that revenue you keep, how smoothly the day runs and when you see your money. In the Netherlands there are dozens of providers, from big names to small niche players, and on paper they look alike. This guide helps you compare fairly on the points that truly matter, and shows how to get the sales figures live into your operations system afterwards.

What choosing a ticketing system really comes down to

A ticketing system is the webshop where visitors buy their ticket, plus everything around it: the payment, the barcode, the scanner at the gate and the overview of what has been sold. Almost every system can sell tickets. The difference is in the details you only notice when it gets busy or when the money has to be paid out.

Before you start comparing, it helps to know what festival.productions does and does not do. We do not sell tickets ourselves and we are not a ticketing company. You choose and keep your own ticketing system, and we connect to it so that the sales figures land live in your budget and your day-of modules. So this piece is deliberately objective buying advice, not a sales pitch.

When comparing, pay particular attention to these points:

The fee model: service fees, transaction costs and who pays

The price of a ticketing system almost never sits in a subscription, but in the cost per ticket sold. Broadly you see two models. Some providers charge a percentage of the ticket price, often somewhere between 5 and 12 percent. Others charge a fixed amount per ticket, in practice roughly between 30 cents and one euro. For more expensive tickets a fixed amount is usually cheaper, while for cheap tickets a percentage can work out favourably. These amounts are indicative, so always check the current terms with the provider itself.

On top of the service fees come the transaction costs of the payment service, such as Mollie or Pay.nl. Count on around 30 cents per payment for iDEAL (the standard Dutch bank-transfer payment method) and a percentage for credit cards. These costs are fairly comparable between platforms, because they come from the same payment providers.

The most important question is who pays the service fees. With many systems you can choose: you add them to the ticket price so the visitor pays them, or you cover them yourself. Having the visitor pay keeps your margin clean, but makes the ticket at checkout more expensive than advertised.

Payout: when your money reaches the account

For your cash flow it makes a huge difference when you get the ticket revenue paid out. Some providers pay out weekly during the advance sale, others only after the festival ends. With some systems the money is in your account within two working days after the event by default, sometimes with the option of interim payouts. This too is indicative, so ask about it.

A payout during the advance sale is helpful if you have to pay suppliers up front, which is almost always the case for festivals. Payment afterwards is safer for the provider, because then there is no money to claw back in the event of a cancellation. So ask explicitly about the payout rhythm and whether an interim payout is possible.

Put the expected payout moments in your budget, so you do not run out of working capital halfway through the build-up.

Scanning and access control at the gate

On the day itself only one thing counts: does the queue get through the gate fast enough. A scanning app on your volunteers' phones is standard by now, but the quality varies. Test in advance how quickly a barcode is recognised and, more importantly, whether the app also works without internet.

At many festival sites the signal is poor, especially when thousands of phones load the network at once. A scanner that only works online then grinds to a halt. So ask about offline scanning and about how the app prevents duplicate scans of the same barcode.

Data ownership, API and integrations

Your festival's sales data is valuable: who your visitors are, where they come from and how sales are going. Check whether that data is yours and whether you can access it. With most Dutch systems you can export the customer data and connect it to, say, your mailing tool or CRM.

For your budget and planning to move along live, the API is most important. A good ticketing system has an API that lets external systems read out the sales figures. Weeztix, formerly Eventix, for example is built entirely on an API and offers hundreds of ready-made integrations, and most other providers offer at least an export or a connection via an intermediate layer such as Zapier.

This is exactly the layer festival.productions plugs into. We do not sell tickets, but through your ticketing partner's API we read the sales figures live and pull them into your operations system. That way you see in your budget immediately what is coming in, and your capacity and day-of modules move with the actual sales, without you having to retype figures.

Queue and peak load during a busy sales launch

If you sell thousands of tickets at once, for example at a popular advance sale that opens at 10:00, peak load is your biggest risk. Technical problems in ticket sales almost always arise from servers that are not prepared for such a rush.

Larger systems handle this with a virtual queue: visitors get a fair place in line and are let in in a controlled flow, like a lock, so the webshop stays up. That keeps sales stable, but it also has a downside. During long waits, visitors drop off. So choose a queue solution that distributes fairly and clearly communicates how long the wait still is.

If you do not expect a stampede, this matters less. For a festival that sells out in minutes, it is one of your first questions.

The well-known Dutch players and doing the comparison yourself

The Dutch ticketing landscape is large and the providers look alike on paper. An objective picture of a few well-known names:

In addition there are dozens of other providers, from TicketView to Tickable, and there are independent comparison tools that let you put ticketing systems side by side. Use those as a starting point, but always recalculate the fees with your own numbers.

When comparing ticketing, also look at refunds: how easily you can refund in the event of a cancellation, and what that costs per ticket. And at white label: whether you can fully brand the ticket shop in your own house style, so the visitor stays within your festival and does not land on an unfamiliar page.

How to get the sales figures into your operations system

Whichever ticketing system you choose, you do not want the figures that come out of it sitting in a separate tab. Your budget, your capacity planning and your run sheet only become truly useful once they move with what has actually been sold.

festival.productions connects to your existing ticketing partner and pulls in the sales figures live via the API. You keep your own ticketing system and your own arrangements on fees and payouts. We are the layer around it: the number of tickets sold flows through to your budget, you see your expected revenue move along, and your day-of modules work with real visitor numbers instead of an estimate.

In practical terms that means: choose your ticketing system on the points in this guide, and while doing so make sure it has an API or a clean export. Then the connection is later just a matter of setting up, not of retyping.

That way the choice of a ticketing system stays where it belongs, with you, while you also make sure the ticket sales do not become disconnected from the rest of your organisation.

Frequently asked questions

Which ticketing system is best for a festival?

There is no system that is best for everyone. It depends on your numbers, your ticket price, whether you need a queue at a busy launch and how quickly you want to be paid out. Compare on fee model, payout, scanning and whether you can read the data via an API, and recalculate the costs with your own expected sales.

What does it cost to sell festival tickets?

Count on service fees per ticket, broadly a percentage of 5 to 12 percent or a fixed amount between 30 cents and one euro, plus transaction costs from the payment service such as around 30 cents per iDEAL payment. These amounts are indicative, so check the current terms. You can often bear the service fees yourself or add them to the visitor's price.

When do I get the ticket revenue paid out?

That varies by provider. Some pay out weekly during the advance sale, others only after the festival ends, and some within around two working days after the event. Because your suppliers usually have to be paid up front, this is an important question. Ask about the payout rhythm and whether an interim payout is possible.

Does festival.productions sell tickets itself?

No. We do not sell tickets and we are not a ticketing company. You choose and keep your own ticketing system. festival.productions is the layer around it: we connect to your ticketing partner and pull the sales figures live via the API into your budget and day-of modules.

Can I keep my current ticketing system and still connect?

Yes. As long as your ticketing system has an API or a clean export, we can read out the sales figures without you having to switch providers. Your arrangements on fees and payouts stay with your ticketing partner; we just make sure the figures flow through to the rest of your organisation.

What is a virtual queue and do I need one?

A virtual queue holds visitors in a fair line at a busy sales launch and lets them in in a controlled flow, so the webshop does not crash. If you sell thousands of tickets in a short time, this matters. If you do not expect a stampede, it weighs less than, say, your fee model or payout.

How do I compare ticketing systems fairly?

Look beyond the fee per ticket. Model your own scenario, number of tickets times price, with each platform's complete cost formula, including transaction costs, refund costs and cost of the scanning app. Then weigh in payout, scanning, queue and the API. Independent comparison tools are a handy starting point.

Sources