How do you Solve a Problem like Fastrack?
Entry posted by JoshC.
4134 views
This is a blog entry that relates to the hot topic of Fastrack and Fastrack sales. So why's it in here, and not in that topic?
The aim here is to illustrate how Fastrack sales affect the main queue of a ride, and demonstrate what many bring up - those who pay for the premium service (Fastrack) negatively affect the service of those who do not pay for such a service (those who use the main queue). Unfortunately, this will be quite mathematically thought out, will ramble on a bit, and uses many assumptions, but nonetheless, it will show just how bad Fastrack can affect the main queue.
Example - The Swarm
I've decided to use The Swarm as an example to demonstrate this point. Why? Simply put, I think there's enough information to be able to show the point.
So, first thing first, where am I getting any information from? Well, the following photo from TTP was taken from the Swarm Behind the Scenes event in April:
The main and Fastrack queues illustrated in this plan seem to resemble that of the real queue lines, so I'll assume that these are the same. As can be seen in the top right corner, there's a bit of rough information about the queues. The main queue is 450m long, and should take 90 mins, whilst the Fastrack queue is 75m long and should take 15 mins (these are presumably guestimates). Strangely, we can see that the Fastrack queue and the main queue have the same length-queue time ratio, in that 5m takes 1 minute to queue. Presumably this would mean the guestimates given don't include the main queue and Fastrack queue working co-currently; in other words, a full main queue would taken 90 mins with no Fastrack whatsoever. The theoretical throughput, again taken from TTP, is 1100pph.
So then, by the guestimates the park has made, a full queue which takes 90 mins will hold 1650 people (in theory). If we divide this down, we find that 28 people, which is a full train, are in (84/11)m of a queue, to be quite precise.
Okay, now this is where I have to make a perhaps strange or unrealistic, to a slight degree, assumption. However, for the ease of calculations, and the fact this is only a rough example, it will have to do. So, I will assume that, on average, at any given point, the Fastrack queue is 2/5 full. So, perhaps confusingly, this would according to above information, only be a 6 minute queue - IF there was no main queue. Yeah, sounds ridiculous, doesn't it?
Anyways, being 2/5 full, this adds and extra 30m worth of queue, if we were to literally 'plonk' these people in the queue. So, being 2/5 full, there are (28)*(30)/(84/11)=110 people using the Fastrack queue. Again, unsure of the realism of this, as I don't particularly pay close attention to how many people are in the Fastrack queue, but I think this seems like a reasonable number in my opinion.
Of course, we would not expect the park to send trains' worth of Fastrack guests round at any one go; it is ridiculous for that to happen. So then, we need to create a form of ratio for the number of main queue guests let in to Fastrack guests let in. Now, I don't know if this is how the park operates it - I'd hope it is something like this though - or what sort of ratio they would use, if they use it. This means I'd have to make a guess, but I'll work out two cases, which are a couple I've mentioned in the Fastrack topic.
Say we work on the basis of 3:1 (main queue : Fastrack queue). In other words, a quarter of the train is made up of Fastrack guests. (NOTE: This would mean 7 people per train, which seems unrealistic, as most people will be going in even numbered groups, but bare with me). Assuming a linear correspondence to this and the throughput, the 'throughput' of the main queue will be 825pph (three-quarters of 1100). Again, I'll assume that we are in a full queue. So, in the space of 90 mins, a person would move 337.5m (which is three-quarters of the queue length). In another 30 mins, you'd move the remaining 112.5m. So then, if just a quarter of guests are Fastrack users, this adds an extra 30 minutes to a full queue. Following some additional calculations, which I can't be bothered to write up here, I can confirm that if a quarter of each ride is made up of Fastrack guests, the queue time of the main queue increases by a third.
I'll cut this second case a bit short, but if we work on the basis of 4:1, a full queue would take 112.5 mins (again, to be quite precise). Again, a couple more calculations confirm that if a fifth of the train is made up of Fastrack guests, the main queue time will increase by a quarter.
Personally, I've always felt that these two ratios are reasonable amounts to satisfy Thorpe's need for money, which is understandable, whilst creating a balance so Fastrack users get their premium service which they've paid for without creating too much hassle for guests. However, this is still quite a large inconvenience for ordinary guests, and it certainly surprised me. This does show how not only does Fastrack offer a premium service, it DOES give a negative effect to those who do not offer such a service.
Overselling and Sales
So, now time to see just how many tickets Thorpe could sell according to this. Let's take a 10-5 day, which would probably be expected to be a reasonably quiet day. Say that the Fastrack sales have time slots from 11am until 4:30pm (half an hour in each slot). This gives 5 and a half hours of the 7 hour day where Fastrack is available.
Taking the first example of 1/4 of each Swarm train being for Fastrack guests, this would mean that a quarter of all guests who ride Swarm in an hour will be Fastrack guests - which is expected to be 275. Multiply that by 5.5 (number of hours in the day where Fastrack is used) and we get 1512.5, round to 1512 for simplicity. This would mean that there's 1512 Fastrack tickets up for sale in a 10-5 day. I don't really know about gate figures or the like, but if we say that there's between 8000 and 10000 guests on such a day, about 15-20% of guests will use Fastrack to get on The Swarm. Reasonable? Again, I'm really not sure, but I was expecting a figure around 10-20%, so I would say so.
Now then, there are of course many issues with this, which I'll explain a bit more in a bit. However, there's the issue of implementing this is reality - it is unrealistic to assume you'll be able to shift the same number of tickets per hour all day, every day. I believe Fastrack works on a half-an-hour basis, so this means that there's about 137-138 tickets for each of these slots, (which is just over the above assumption that at any given time, on average, the Fastrack queue is 2/5 and has 110 guests waiting). No doubt it's possible to think that, time slots will be more popular and others less popular, which could possibly lead to there being more slots designated to the popular periods of the day, and less to the quieter periods. It does mean that we could easily see a queue time increase by 40% (which, to reiterate the long running point, would mean the main queue for Swarm would be nearly 130 mins - over 2 hours - when it would only be 90 mins with no Fastrack at all...). Another issue, which has been pointed out in the Fastrack topic, is time slots and how they are kept to, or rather how they are not. Say a 'popular' time slot is 1pm, and many people missed their half-12 slot because of eating lunch, waiting for their lunch to go down, had the intention of going at 1 anyway or whatever, a Fastrack queue which can increase a queue time by 40%, can easily increase it by even more. Okay, I'm belabouring on the point here,
Ways to Solve?
So, this is where the blog becomes rather similar to the post in the Fastrack topic. Before I carry on, I'd like to say that with the two ratios I looked at, 3:1 and 4:1 Main Queue-Fastrack Queue (ie, a quarter and a fifth of the train full of Fastrack guests), we're looking that on average, about 6 Fastrack guests per train for Swarm. In turn, this will increase the queue by about 3/10, such that a full queue line will approximately take nearly 2 hours, 117 mins to be precise, as opposed to 90 mins. The idea that 6 people per ride are Fastrack guests is a little on the conservative side in my mind in my opinion.
One way to solve it would be to increase prices and decrease the availability of tickets. This way, the park still make money a plentiful with Fastrack, and will not lose out on cutting tickets. Again, using Swarm as my example, if instead of having 1512 tickets, it went to 1000 (again, to make life easy when doing calculations). So, this cuts the tickets available by a third, meaning we have about 92 tickets available for each slot. Cost-wise, at the moment, if everyone bought a Swarm Fastrack (again, to make life easy, let's just assume there's no front-row Fastrack and all tickets are £5), then 1512 tickets in a day would create just over £7560. If we cut tickets by a third, and raise the cost by £1 (a fifth), meaning people would pay £6 for one Fastrack, which no doubt people will willingly pay, they earn about £6000, losing £1560. Now, I guess one great thing for the parks is Fastrack will pretty much be all profit - ticket printing costs are low, and it won't require many, and in some cases, any, extra staff on rides. So, I'd assume that what is quite a large change in money earnt won't stop profits, just decrease them. However, I'd be quite confident in saying that if the park were to advertise 'Fastrack tickets are limited all day and certain time slots sell out quick!' or something, people will happily part with their money even if the cost has gone up and, dare I say, I think the same would happen if a Swarm Fastrack cost £7.
A couple of other options would be to implement just one of these without the other; either just outright increase prices, or outright decrease availability. The former of these two options means more money for Merlin, but possibly less people willing to pay if it's not as premium as they expect (ie - having to pay a large-ish amount to queue for a period of time which they'd judge as not worth the additional cost). However, we have seen prices slowly creep up over the years, and I believe that this will continue and prices will naturally get a bit more expensive, especially with the packages. The latter of the two means a full out decrease in profits for Merlin, which in terms of a company, is a bad thing. Not to say that they would never do it, but I can't see it being considered, or considered to a degree such that it would be noticed.
A different and, in my eyes, most sensible and realistic idea would be to be stricter with the time slots. I guess Fastrack tickets have half an hour time slots, and it states on the ticket 'To be used within 30 minutes of the time printed on this ticket'. Yet, by the sounds of it, as long as you arrive after your time, it's fine. Why not actually enforce such a thing? Well tickets are sold, tell the guests verbally 'You have to use it within 30 mins of the time printed or you can't use it' and print it on the ticket, along with 'no refunds'. That way, they still make their money, and people have been warned - surely unless there's a valid reason for missing it (stuck on a ride, breakdown extending queue length and so forth), it's not the park's fault, so why should they have to refund it? The issue is of course people aren't always great with time management, especially if they've never visited a park before, so this may be a bit harsh / need refining.
Another thing I'll briefly mention is the Fastrack packages. How exactly do they work? Is there a specific time slot for them and how does that work? Maybe they can designed so that they're as strict to times as possible, whilst still giving enough lee-way? I really can't comment much on this, and can't think of much to say seeinghow I've never had any experience with the way the packages work.
So, that is that. Fastrack has a negative effect on the main queue line - fact. However, there's an issue with everything that I've gone through. I've been concerned with the queue length, queue time, etc. of the main queue, but mentioned nothing about how long the Fastrack queue will actually take. This is something I won't actually try to work out at this stage, but may do it at a later date. However, if it turns out that this leads to the Fastrack queue being not-so-fast, then all of this is pretty much...complete twaddle and everything I've modelled would need refining. I'll also point out again that I've made many assumptions here for the sheer ease of calculating this, so there will be things such as 'Hey, that's unrealistic, that would never happen', but hey-ho, life carries on..
Thanks for reading this and hope I haven't been babbling on about complete rubbish all the time. As said, if anyone sees any mistakes / problems with this, just say, as I may well have made a silly mistake somewhere. For now, that is well and truly that!
2 Comments
Recommended Comments