Eurofurence Information > Feedback
Queues and Queuing: The Who, The Why, The Where and the When
Cubitus:
True so true. So you need more/more dominant staff. "NO, doggie. You don't queue NOW. It's to early. I will throw you a stick. Go get it!"
On the other hand team would have to decide or find out: how long in advance is the right time to start queueing. "DOORS OPEN" - too late. 3 hours - too early. Maybe in the moment when show team says "We're ready to go" and get another 15 Minutes to prepare themselves for the show. Difficult challenge with the masses.
Estrel should recommend and say how THEY do it. But their show audience is different: they bunch up in the lobby, having a drink until seating starts. EF attendees want to see a dozen panels, shaking hands, elevator rides and grabbing food, all of this at the same time :)
Wawik:
I haz e-z solution ! ;D
Cubitus:
Has to work with a gun class below Nerf. Difficult :P
Runo:
--- Quote from: Druon on 07.09.2014, 15:26:29 ---I think we need to focus on maybe less elegant, but far more practical solutions. One thing I have in mind is to handle delays with pessimistic time estimates, rather than optimistic ones. It means that an event that is delayed due to technical issues of any kind will automatically announce a set amount of time for the delay, say an hour, to give them proper time to fix it as well as make things easy to communicate to the waiting audience.
--- End quote ---
This would only work if the events weren't packed as tightly as they are. As it stands, the timetable only works if and because delays are kept as minimal as possible, because any delay affects all following events in the same space, there's just no buffer to catch up on lost time. And we can't just pack less tightly, because there are just so many events, and so little space…
Believe me, if solutions were that easy to implement, the people responsible for that would have already done so. :)
Fineas:
--- Quote from: Cubitus on 07.09.2014, 10:11:03 ---
--- Quote from: Cheetah on 04.09.2014, 10:55:35 ---
--- Quote from: Tinka on 04.09.2014, 10:37:18 ---4. Ones all the delays and further delays have been announced - and the door are about to finally open - everyone takes their place in the queue and walks in an orderly fashion to the stage :33
--- End quote ---
What you're suggesting is basically this:
[...super funny image...]
--- End quote ---
... Long queuing explanation..
--- End quote ---
I would personally vote for a far simpler system. The ticket thing is used in bakeries, butchers and pharmacies.
Average load their is like... 40 people tops.
So I would like to stress that using it for 800+ people is going to be a stretch.
However:
* Just put up a ticket machine with 2 colors (super/sponser and regular)
* Then give a 30 minute call out (which will add a default half an hour delay to a possibly already delayed show, but that would be the only way to reach out to everyone even if you are at your room through EF prime) for everyone to group/que up according to number.
* Let the first 10 people enter and then handle the next 10.
* If everyone is their and has shown up, immediately let the next 10 enter, else respect some 'grace time' (10 sec with an additional call out through the lobby/que) for stragglers with lower numbers to enter the show.
* Send everyone off to re'que with a higher number.
* Let everyone with a far lower number through also off course.
What ever we choose however:
* It will cost extra time and man power (mainly and probably from security)
* Delays might and will occur regardless of the system, so the only thing we actually do is make it more orderly/easy for attendees
* Any system that includes more complexity will probably cause problems: 'I lost my ticket', 'I am a (super) sponsor and got the wrongly colored ticket' etc
Looking at this it might be easier to try and fix redundancy as far as possible (preventing delays).
Try and keep guests inside so they don't wait in the cold and entertain them somehow (the impromptu AJA performance for example).
And if possible come with an accurate delay, which as far as I have been able to deduce is nearly impossible.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version