Big parks have queues of up to two hours.
A virtual queue for the whole park, inside your own app. Visitors know their ride time before they wait, and in the meantime they eat, shop or catch a show. We show you how it works with a sample park and made-up data.
There aren't enough places for everyone, and those who miss out only find out after an hour in the queue.
The data as a table
| Ride | Average | Daily maximum |
|---|
In the sample park, 14 rides have an average wait of 25 minutes or more. A peak day is far worse.
A virtual queue doesn't make any ride bigger. Magma can take about 7,000 people a day, and on an average day the park has about 12,000 visitors. A virtual queue shares out the places as the day goes on, tells everyone when it's their turn before they wait, and gives them back the time they would have spent queuing.
We're not proposing a trial on a single ride, but the whole park, built into your app and into the way each ride is run.
Four steps, all from a phone.
Book
Up to three rides, in any order. Each one gets a time, allowing for the walk from one to the next.
Meanwhile
Eat, shop or catch a show. The app suggests whatever the park has chosen to offer.
Reminder
A few minutes beforehand. If plans change, cancel, and the place goes to someone who can use it.
Go in
The phone shows a QR code that changes every few seconds, and staff scan it, even offline.
Without the app, ride staff scan the visitor's ticket and give them a time. Places are released in waves: every hour, those for two hours later. So someone who arrives at midday can still get a time on the most popular rides. If a ride stops, the system moves the times or, once it reopens, offers a new one in queue order.
The app, screen by screen: a family's day
A booking, from start to finish
The same day, with physical queues and with a virtual queue.
A Saturday with 20,000 visitors in the sample park, with the same people and the same breakdowns both ways. The simulation was run by the same engine your app would use: you can follow its log next to the map.
Loading the park data…
People who aren't queuing spend. Adjust the assumptions.
Extra spend per season
–
| Gross margin for the park (65%) | – |
MassiuSoft's fee will be agreed in negotiation.
MassiuSoft's estimate for the sample park, based on its waits, opening calendar and the capacity of each ride, all made up. With your park's waits and sales data, the figure will be your own.
Your whole park, for one season.
| When | What |
|---|---|
| The first two months | Agreement, access to the integrations and settings for each ride |
| The next two months | The kit in your app, set-up, staff training and a contingency drill |
| Start of the season | Go-live across the whole park |
| During the season | Weekly review and fine-tuning of the settings |
No building work, no hardware. For each ride, one or two phones for staff and an outdoor tablet. The staff app works offline and takes half an hour to learn.
The integrations: the kit inside your iOS and Android app, checking ticket codes, ride status, priority passes sold each day if you sell them, and sales by outlet and hour, to measure the results.
MassiuSoft's fee will be agreed in negotiation. The app and the data are yours.
Digital products on our own infrastructure.
MassiuSoft is a Catalan technology group. Our products run at EUginy, the group's server farm in Santa Maria de Palautordera, on its own solar power. We build on what already works in our other products: SinCaja, checkout-free shopping for supermarkets, with a kit inside each chain's app and an exit QR code validated on the server; and NeuMaps, routes and guidance for skiers, with live alerts and groups.