Better wait time estimation

[KeithVH]

So we have FLIK cards which are sent through a queue periodically. Yes, pretty accurate but not necessarily consistent. Then there's the phone apps that aggregate individual's arbitrary input of the time they think. Neither are perfect. Why can't they use the MagicBands?

They know, within a minute, how long a ride is. Why can't they poll all IDs within a limited area, like a queue, subtract the ride time, and average/aggregate the time that a bunch of IDs are all within that select area to determine wait times?

 

[danlb_2000]

So we have FLIK cards which are sent through a queue periodically. Yes, pretty accurate but not necessarily consistent. Then there's the phone apps that aggregate individual's arbitrary input of the time they think. Neither are perfect. Why can't they use the MagicBands?

They know, within a minute, how long a ride is. Why can't they poll all IDs within a limited area, like a queue, subtract the ride time, and average/aggregate the time that a bunch of IDs are all within that select area to determine wait times?

I have always wondered this also. A reader at the start of the queue and another at the end would work just like the card they currently use, but it would get updated much more often then the cards.

 

[Tom]

I have always wondered this also. A reader at the start of the queue and another at the end would work just like the card they currently use, but it would get updated much more often then the cards.

Right. I've seen this as an obvious addition since the start. The problem is that the start of the queue moves, so the entry point couldn't be a fixed portal.

But an "area" could be scanned.

 

[RobidaFlats]

Right. I've seen this as an obvious addition since the start. The problem is that the start of the queue moves, so the entry point couldn't be a fixed portal.

But an "area" could be scanned.

Unless the queue has extended past the physical entrance, it should be fine to use that as the fixed point. That's basically what they do when they hand out the red tag to a random person entering the queue anyway. If it's extended past that point, the sign could just read "A LONG TIME", haha.

On a related note, it would be interesting to see the data on the average wait of fastpass users (since those are already being scanned) on given attractions.

 

[Phonedave]

I guess they could, but it still would have accuracy limitation.The attraction has an average throughput time, but all you need are some slowdowns in the queue ahead of you, and all averages go out the window.

-dave

 

[daringstoic]

Plus there's still the problem with a lag in the wait time updates. I used to see it all the time when I was in attractions. The line would dwindle to half an hour or so during parade time and then a thousand people would pour into the queue past the 30 minute wait sign. The people at the tail end of the rush would be looking at an hour or more even though the sign still said 30. Even if you handed out the flik cards immediately or scanned magic bands, the wait time doesn't update until they get to the front of the line...an hour later. The flik system is pretty good overall, but it doesn't react well to sudden changes in line size. Things are probably a little different now, but it was very hard for us to get managers to override the flik scans and bump it up manually. I used to try to manipulate it by scanning cards early and letting them sit if I was there around when I knew we were going to get slammed, but it was hard because we were constantly rotating to new positions.

 

[RobidaFlats]

Plus there's still the problem with a lag in the wait time updates. I used to see it all the time when I was in attractions. The line would dwindle to half an hour or so during parade time and then a thousand people would pour into the queue past the 30 minute wait sign. The people at the tail end of the rush would be looking at an hour or more even though the sign still said 30. Even if you handed out the flik cards immediately or scanned magic bands, the wait time doesn't update until they get to the front of the line...an hour later. The flik system is pretty good overall, but it doesn't react well to sudden changes in line size. Things are probably a little different now, but it was very hard for us to get managers to override the flik scans and bump it up manually. I used to try to manipulate it by scanning cards early and letting them sit if I was there around when I knew we were going to get slammed, but it was hard because we were constantly rotating to new positions.

This is an important point that I didn't think about. Rapid fluctuations due to weather, parades etc. would be hard to compensate for.

 

[FrostyNaples]

How can you take something Dynamic and make is Static? You can't.

We shouldn't be asking ourselves how long the wait is, we should be forgetting that we are waiting.

There needs to be elements start to finish to distract, interact, and entertain you until its your turn. You'll then forget "time" was even something you were trying to figure out.

 

[Variable]

This is kind of like people who want online bus ETA etc times.. They want to wait in their rooms until the bus is "just minutes away" . Then they'll calmly, I guess, walk to the bus stop and discover: a crowd of people getting onto the bus and they'll be among the last ones on. And if that ETA shows up online as 5 minutes, they leave the room/hotel whatever, and something happens to delay that bus a few minutes? WAHH WAHH WHAHHH

 

[Stitch_Fan_NJ]

I don't think wait times have ever been accurate in WDW.

What is assuming is the wait time boards in future world that are often times not even close to the actual wait time (usually time listed is way longer than the actual time you'll wait).

Guess that could be contributed to lag in the system or just a "broken" system in general. I think if you go to WDW enough you can look at where the end of the line is and make your own estimate on the wait time (I know this doesn't work for every attraction)

 

[RobidaFlats]

This is kind of like people who want online bus ETA etc times.. They want to wait in their rooms until the bus is "just minutes away" . Then they'll calmly, I guess, walk to the bus stop and discover: a crowd of people getting onto the bus and they'll be among the last ones on. And if that ETA shows up online as 5 minutes, they leave the room/hotel whatever, and something happens to delay that bus a few minutes? WAHH WAHH WHAHHH

Your hyperbole is nice, but in some instances, the posted wait times are of some real value. For example, a ride such as Space Mountain has a hidden queue. If you walk by the entrance you have no way of knowing if the line is backed up to within 10 feet of the first turn and fully wrapped in front of load, or if it is empty the whole way. Having an estimation will help me determine if I want to ride or head over to something else.

 

[Variable]

Your hyperbole is nice, but in some instances, the posted wait times are of some real value. For example, a ride such as Space Mountain has a hidden queue. If you walk by the entrance you have no way of knowing if the line is backed up to within 10 feet of the first turn and fully wrapped in front of load, or if it is empty the whole way. Having an estimation will help me determine if I want to ride or head over to something else.

Thanks, I've been taking lessons from others.

We've used the boards occasionally, why not. Oh look, it says ToT is x, etc. Lets go there. Get there, no its not x anymore, its y. And it took us what, 2, 3 minutes to walk over there? So much for the value of the board.

Its a dynamic situation. And having all this data on one board, many minutes away from the actual ride, brings in a lot of ... variability ... and the reliability of the data goes down. Inevitably there will be complaints, i.e. whining, that its steered somebody wrong and they missed their once in a lifetime opportunity yada yada yada.

For many many attractions a wait time of 10 - 15 minutes "from this point" is darn near a walk on, especially if the queue LENGTH is long.

As the parks have gotten busier, and the app has become available, we check the app, make a decision to head over somewhere and check it out. Seems precise enough for us. Often we just go find the things we really want to ride on, and enjoy the wait if we don't have a FP.

In the end we don't worry about 'touring' and "doing everything efficiently as possible" because we don't go to WDW just to ride rides. I guess we just don't know "how to do Disney" Odd that we have such great trips though.

 

[Tom Morrow]

Plus there's still the problem with a lag in the wait time updates. I used to see it all the time when I was in attractions. The line would dwindle to half an hour or so during parade time and then a thousand people would pour into the queue past the 30 minute wait sign. The people at the tail end of the rush would be looking at an hour or more even though the sign still said 30. Even if you handed out the flik cards immediately or scanned magic bands, the wait time doesn't update until they get to the front of the line...an hour later. The flik system is pretty good overall, but it doesn't react well to sudden changes in line size. Things are probably a little different now, but it was very hard for us to get managers to override the flik scans and bump it up manually. I used to try to manipulate it by scanning cards early and letting them sit if I was there around when I knew we were going to get slammed, but it was hard because we were constantly rotating to new positions.

Another problem FLIK doesn't account for is sudden surges in Fastpass queue users. The wait times are generally based on a standard Fastpass queue/Standby queue ratio, but if the Fastpass queue becomes too full then they have to pull even more guests from the Fastpass queue than normal.

Most attractions have some sort of formula that they teach CM's, combining where the end of the line physically is with the number of operating ride vehicles. These are usually pretty accurate so an experienced CM at that attraction can usually give you a pretty accurate estimate.