Leaderboard

Wonderful news. I know they've been talking about it behind the scenes for a while, so good to see it's come to fruition. I know some people will say the park should be open that later regardless over summer, but it has always been the case that the demand isn't there. Trialling it / doing it on select days helps test the waters. Hopefully this can be a step to later summer closing, and maybe even the park testing 10pm Fright Nights closes again.

Opening hours have been extended until 9pm on the last 2 Saturdays of August (24th and 31st) Great to see - especially at a time when hours are being cut on a weekly basis at Towers at the moment...

Similarly to you I’ve always found the back to be smoother, and the inside seats to be smoother as well. Front row outside seat is just god awful these days. But I guess it fits the theme better than it ever has before 😂

From my personal experience, I don't really find a difference with what row I sit on. I find different trains to be rougher than others though, I imagine that depends on which ones have recently been serviced, and had wheels replaced etc...

Excellent news! Hopefully the extension of hours rather than cutting hours like Alton Towers are is a sign of Thorpe Park doing well this year! My only concern, though, is that there may not be demand for it. I remember Thorpe Park doing 8pm closes back in August 2019; I went to one of them, and the park had completely emptied out before 6pm. It was brilliant for repeat riding, but a damning indictment of the demand for late night openings… those 8pm openings were quickly dropped shortly after my visit. This is a positive sign on the whole, though! I don’t know if anyone else agrees, but overall, it does seem to me like Thorpe Park is the most prosperous UK Merlin park this year. The Hyperia buzz could be partially contributing to this, but it doesn’t seem like Thorpe has the general air of negativity surrounding it that Chessington and particularly Alton Towers currently have.

Passholders whine more than anyone. I'd want to maim people if it were me dealing with it. Which was probably half the issue with the often sarcastic responses from Thorpe. Fine for an individual, but not when representing a company.

I can give insight here. A few years ago (well, more than a few years now...8 years ago...I'm old), I had a job at Thorpe which was focusing primarily on 'looking after queue times', if you will. I had to update queue times that would appear on the boards, along with some other things. At the time when I joined, it was simply a glance and estimate. It was a two-way operation: the ride operator was required to contact the 'queue person' (ie: me) via phone once an hour (at a minimum), saying what they thought the queue time was. The queue person would also walk around the park, visually looking at all queues and updating the queue times. How is it physically done? All updates were done via a secure webpage. The queue person walked around with an iPad and could update directly all queue times from said webpage. Other people (park managers, etc) had access and ability to as well (will get onto this later). How would ride operators know what the queue time is? This was done by looking at the length of the queue, which for many rides, they could only see through via the ride's security cameras. The security cameras ride operators have access to focus primarily on ride areas (making sure no one is entering them), meaning coverage was mixed. Ride operators would sometimes not see much of the queue. Note: Queue lines are still covered by CCTV cameras, but ride operators won't have access to them all necessarily. The ride operator job is to run the ride safely. And that's a key point, the ride operator is there to run the ride safely, look after the ride hosts, etc. Updating queue times can go quite low on the list of priorities. Also, ride operators generally didn't have much knowledge of queue times. It would all be based on own experiences, either from when they might have visited the park and queued themselves, other operators, what guests say, etc. Generally they would get good ballpark figures, but when you hit busy periods, that experiential data is less helpful. How would the Queue Person know what the queue time is? Same idea. They would walk around, see the queue time, and update it. The advantage they had is they could see the whole queue, and have knowledge of what else is going on around the park. Eg: Colossus operator might not be aware that Saw closed down recently, meaning more people might flock there if they're nearby and want to ride a coaster. Queue Person would know this, and could keep a closer eye as a result. So it was all guesswork? Going onto my experience of working in this position as the queue man. I noted straight away there was very minimal written down information about how the physical length of a queue translates to a queue time. Of course, everyone was aware that this is a very muddled science: it depends on operations, number of trains, number of Fastrack / RAP users, delays, etc etc. Many of those things ride operators will not be aware of explicitly. Some of those things are out of a singular person's control. However, there is a way of turning it into a science. "Queueing theory" is a very rich area of maths, for example, which gives us many lessons we can learn. There's a lot of social science studies into how people will fill up a given space with strangers. There is access to lots of data about the rides; their uptime, their throughput/utilisation, so on and so on. You can combine all of those factors together to give a better estimate for queue times, one which relies on data, rather than just guesswork. Taking the Guessing out of the Guesswork I'll chuck in a bit of the numbers and theory here. Feel free to skip over. When thrown into a barriered queue, you'll find people spread out in similar ways. Except in extreme scenarios (very wide or very narrow queue lines), about 11 people will fill up 3m of space. This is to do with how groups of people will huddle together, groups will leave a space, etc. That data comes from a published research paper back in 2014/15 I believe and focused on UK audiences. Would be interesting to see if that's changed post-Covid, or is different in other countries. Anyways. If we know that, we can work out how many people a physical queue line holds. For example, if the Colossus queue line was 300m long, it would hold roughly 1100 people. And you can split that up; if the queue line from the airgates to the tunnel of Colossus' queue was 90m long, the number of people between the queue line and boarding is 330. (NB: Lengths made up). Now, we know what Colossus' theoretical throughput is. Internally, there is also a target throughput. But even better, parks track their throughputs for each ride. So you can see what they're actually achieving. If, over the course of last week, Colossus got a throughput of 550pph, and it had a full, 300m long queue line, you could see that it should be a 2 hour queue. Obviously that ignores Fastrack and RAP users. But again, you know the number of RAP and Fastrack users each day. You can take those into account, in some way. You don't know when they're going to use, but you can take it into account. For example, if there were 700 Colossus Fastrack tickets sold for an 8 hour park day, and 500 RAP users expected, you can account for that. If Colossus was getting a throughput of 550ph, over 8 hours it would get 4400 riders. But 1200/4400 of those riders came from Fastrack or RAP. So that means only 73% of riders are coming through the main queue, or rather the throughput of the main queue is 73% of 550, which is 400pph. Now if that 300m long queue of Colossus is filled with 1100 people, and you know 400pph are going through that queue, you can advertise the queue at 2h45min, rather than 4 hours. (Again, all numbers are fake here) On top of that, you can also take into account the chance of a shutdown. If Colossus has an uptime of 95%, then that means its closed 5% of the time. Of course, this is unlikely to spread evenly across the day, and usually occurs in a chunk, but if you add on that extra, you create a buffer which allows for a 'chance of shutdown', or just anything going wrong (slower operations, etc). I'll take this chance here to say: ride staff do not artificially inflate queue times to sell Fastrack tickets. I've no doubt it happens whereby a queue is advertised much longer than it is, and people have ended up buying Fastrack. But the queue time is not inflated to drive Fastrack sales. In saying that, I think it's better to advertise a queue time which might be 5-10 minutes longer since it will: 1) Create a buffer in case of issues and 2) Create happy guests - "Oh, the queue was advertised as 50 minutes, but we actually queued 40...result!" So, the way that I planned to calculate (note the word calculate, not estimate/guess) queue times would be: (N*(1+D))/(T*(1-(F/R))), where: N is number of people in queue D is percentage downtime T is throughput F is number of Fastrack and RAP users expected R is total ridership expected for the day Those 4 last variables would be based off numbers from how the ride has run over a period of several days / weeks prior, giving it a good outlook at how it should operate in practice. It wouldn't be perfect, but it does the job. And of course, number of people in a queue is again estimated, but can be done reasonably well. Of course, this isn't something that can be done in your head or anything, but can all be programmed to be done automatically, so long as you say the number of people in the queue roughly. When I trialled this system, it worked well, with overall accuracy of queue times improved, and less complaints about inaccurate queue times, which also saw a reduction in complaints about queue times altogether for a short period of time. (Those two might not be linked, but I'm gonna claim it's because of me). I'm a Celebrity was one which hugely benefitted, in part down to the huge buy in from the Entertainments Team running it. The issue here is, simply put, getting buy in from others. I required a bit more help setting up the automation and implementing it on a broader scale. Some people are opposed to change, some people are opposed to change where they don't understand every detail, some are just happy with the way things are. Some of Matt's analysis here is exactly the sort of thing which would be excellent for the operations teams at Merlin theme parks to see, so they can have more detailed data to help them determine how they're performing and the reflection on advertised queue times. But from my past experience within the parks, you would find yourself encountering people who: -Don't understand the analysis behind this, so immediately disregard it, -Would love the bottom line, but wouldn't use the data to help improve it, -Disregard everything and say everything is fine, -Agree with everything, but don't have the time/resources to action upon anything that would help. Obviously, with shifts in Merlin, this may be different now. But it's such a difficult thing to achieve. There are (naturally) some excellent data-driven minds who work in Merlin, who would love this stuff too, but they are used in other roles, usually outside of day-to-day operation / outside of attractions entirely. So Merlin know the importance of these things, it just hasn't trickled down to operational success. My time within the queue person job ended back in 2017, and this isn't the place to discuss that. But ultimately, the system devolved into operators phoning a central figure in an office to update queue times, with managers also chipping it. Likely with zero consistency. I don't know how things are this season admittedly, and I've been impressed with the accuracy being better than it has in the past. So maybe they've got something a bit better now. FAQ Do all parks do this guesswork? Within Merlin, I believe so yes. I think Towers have staff at rides update queue times, and Chessington was similar. Why did Thorpe need a central figure to update queue times? Couldn't it just be done by each ride through the website? The issue with the website and multiple users would be the constant need to refresh. If, say, there were 2 people on the website, and Person A updates Colossus' queue time from 10 minutes to 50 minutes, the site according to Person B would still have Colossus' queue time listed as 10 minutes, even though it was displaying on boards as 50. Then, if Person B updated Swarm's queue time from 30min to 20min, without refreshing the website, they would also update Colossus' queue time back to 10 minutes. So yeah, clunky system. I don't know if they've updated this. *This park* advertises queue times super accurately, how do they do it? I don't know. I would love to know how parks like Efteling, Europa, etc do it. Why can't parks just count the number of people going into a queue and going on a ride, using barriers, infrared, whatever? These work nicely in theory, but are open to abuse (people spinning barriers) and prone to error. The Alton Towers app had some Bluetooth tracking tech a while back, where it could see where guests were spending more of their time, etc. I don't know if they still do that, but I believe attractions.io (the company that does the Merlin apps and more) have loads of cool backend features. With Saw though, they had a very cool (rather complicated) piece of software they trialled. The name escapes me, but I'm sure I'll find it sooner or later. Basically though, it would track people in all queue lines, to see how long people were spending in the queues, and use it to give accurate queue times. It would update regularly, and give to the minute readings (eg, 47 minutes). This software was just installed to work with existing CCTV cameras. And, it worked well. Very well. Queue times were accurate. The system wasn't prone to error or breaking. It just worked, so you could leave it. In saying that, there were operational issues: -If you ever needed to over-ride it, you had to reset all the cameras to get the system back -It would never display a queue time lower than 10 minutes -It didn't work when the queue became external (ie out of the main queue) -People were weirded out by the exact numbers The middle two are the bigger issues here, but again, not huge in the grand scheme of things. There were bigger, more damning issues: -It was expensive. I don't know how much, but given every other queue time system is free pretty much, spending money on one is an issue. Spending lots of money is a bigger issue. -It required static CCTV cameras on the entire queue line. Whilst the entirety of Thorpe Park is covered by CCTV, many of these have the ability to change angle, which can help in a security situation. If you needed static CCTV cameras for the queue lines, it meant having to buy, set up, operate and maintain more new ones. And for some queue lines, this would require an awful lot (Colossus would be nightmare, with its sprawling queue line, going through tunnels, foliage, etc). Ultimately, whilst it gave accurate queue times, the initial outlay cost, and ongoing maintenance costs, weren't justifiable. Do accurate queue time really matter? Just to round off on this very long, tangential post (sorry Matt!). How important are accurate queue times? At the low level, yes, it's handy to know if a queue is 5 minutes or 10-15 minutes. At an extreme level, it's good to know if a queue is 1 hour or 2 hours. But beyond that? Does it matter if a queue is 30 minutes or 35 minutes? 110 minutes or 130 minutes? I think sometimes there's an overpush on queue time accuracy: if a queue is advertised at 110mins and I queue 130mins, I've still queued about 2 hours for a ride, with added annoyance that I've queued an extra 20 minutes than I was told. It might be better if there's ranges that are advertised (0-10, 10-20, etc, 90-120, 120-150, etc). It buckles you up for the length of the queue, tempers expectations, but gives leeway for a park too. You can have the most accurate queue times in the world, but if they're long and / or slow, that's all people will care or remember about.