What the park earns when people wait outside the queue.
Waits and each ride's capacity give the hours spent queuing: here, those of a sample park, with made-up data. The commercial assumptions say how much of that time ends up in food and retail. You can move all of them.
Extra spending per season · food and retail
Between 1.2 and €16.7M depending on the commercial assumptions (cautious and optimistic).
+19% on current food and retail spend · €27,000 per day open
MassiuSoft's fee will be agreed in negotiation.
What happens in a season
What matters most
Extra spending, in €M, if each commercial assumption moves from cautious to optimistic and the rest stay as they are.
What about the priority pass?
The 14 rides with the longest queues.
An average posted wait of 25 minutes or more. The virtual queue covers every ride: the rest are summed up at the bottom. Hours are per season and are recalculated with the assumptions.
| Ride | Average wait | Daily maximum | Theoretical capacity | Queuing hours | Hours freed |
|---|---|---|---|---|---|
Five steps, with the sample park's data.
Riders on each ride. Theoretical capacity × real capacity × 90% running time × 2,300 opening hours a year. Water rides only count the warm season. If the average wait is under 15 minutes, the ride isn't full and the number of riders is scaled down in proportion.
Queuing hours today. Little's law: riders in the standard queue × real wait. The real wait is the one posted in the app, corrected; priority pass riders don't count.
Hours freed, on every ride. With no physical queue, everyone books a time, in the app or at the ride entrance. Each rider saves the real wait minus the minutes they still wait at the entrance. People without the app also lose the time it takes to walk to the ride and book there.
Spending. The spending rate is what the park already takes today per hour outside queues: food and retail spend per visitor ÷ (visit hours − queuing hours). It's applied to the freed time that doesn't go into another queue, multiplied by the intensity.
Margin. The park's gross margin on the extra spending. MassiuSoft's fee isn't deducted: it will be agreed in negotiation.
The calculator falls short, on purpose.
Averaged over the year, the simulation cuts queuing from 5.1 to 1.9 hours per visitor per day: a saving of 3.2. The calculator starts from 3.1 hours of queuing and frees 1.5. It uses the year's average waits, but most visitors come on the busiest days, when queues are longest. We'd rather the starting figure was a cautious one.
What the pilot will need to tell us
- The real spend per visitor per hour, from the park's tills. The figure here (€10–14 excluding VAT) is a generic estimate.
- The real capacity of each ride. Big rides usually run below their theoretical capacity, and the model assumes 60%.
- How many people buy the priority pass and how much it brings in.
- How much of the freed time ends up in food and retail. This can only be measured with a control group that has no virtual queue.
- How many visitors use the app and how much time people without it lose.
- Not counted: spending outside the park, revenue from selling the virtual queue, or the cost of setting it up.
Sources
- The Amusement Park is a sample park: its rides, capacities, waits and visitors are made up by MassiuSoft, at the scale of a large European park.
- Real capacity, real wait, priority pass, water season and spending model: MassiuSoft estimates, which each park replaces with its own data.
- The simulation runs the real queue engine, calibrated to the sample park's waits.