I have received some concerns about the workflow for events with RSVPs and waitlists, and I wanted to check how others feel.
SCENARIO:
Let’s assume there is an event with RSVP enabled. The max number of RSVPs is 10, Enable waitlist is turned on, and it is set to 10.
All RSVPs have been taken by the following:
User 1 - 1 attending
User 2 - 4 attending
User 3 - 2 attending
User 4 - 2 attending
User 5 - 1 attending
Then, the following users, in order are added to the waitlist:
User 6 - 2 attending
User 7 - 1 attending
User 8 - 1 attending
At this point, we would have the following status: 10/10 registered, 4/10 on the waiting list.
TESTCASE:
User 1 cancels their registration, leaving 1 spot open. What should happen?
EXPECTED OUTCOME:
Since User 6, in the waitlist is looking for 2 tickets, User 7 should be registered as the next guest.
OUTCOME:
No users on the waitlist are registered and the seat is available to the public. If User 7 or User 8 notice that a seat is open and attempt to register, they are denied because they are already registered on the waitlist.
If the first person in the waitlist is not eligible for the opened seat, it should go down the list until it finds someone eligible. If no one on the waitlist fits the criteria, then maybe that seat would be "locked".
A “locked” seat would only be available if:
Waitlist is empty
More seats become available and someone in the waitlist is eligible.
There is still room in the waitlist, and someone joins. Essentially they would be skipping the line, but at least all the people in the waitlist before them had a chance to get it first.
Thanks for spelling this case out for us. I see what you mean about when 1 spot opens up and the waitlist is
User 6 - 2 attending
User 7 - 1 attending
User 8 - 1 attending
where you’d want User 7 to be confirmed.
However, carrying that logic forward, I can imagine that situation where 1 spot opens (and User 7 takes it), and then a 2nd spot opened up (and User 8 takes it), then User 6 wouldn’t have gotten confirmed even though they were “first in line,” because the 2 seats opened up sequentially rather than all at once. Hmm.
If folks feel strongly it ought to be the other way, we can explore a core change that would allow that (or maybe make it a site-wide configurable option), but I do feel on the fence about changing the behavior, since I can see both sides of it. I’ll keep tabs on any further conversation about this; thanks!
I did think about the scenario where User 6 could miss out if two seats eventually opened up. That’s why I suggested possibly “locking” seats, but that approach could get complicated quickly and probably isn’t ideal.
There are a couple of concerns I can see:
Very low odds for later users
User 6 has a pretty low chance of getting in, and Users 7 and 8 are almost at zero. If a user knew User 6 is waiting on two seats, it might be better for them not to join the waitlist at all and instead just refresh daily to see if anything opens up. Because of that, it would be nice if Users 7 and 8 had at least some chance, since they did sign up.
Potential for sabotage
Someone could intentionally register with a high number just to block everyone else on the waitlist. A person could use a fake email, camp the page, and grab seats instantly the moment they open, bypassing the whole waitlist entirely. Unlikely, but possible.
Honestly, there are pros and cons to any solution, so I’ll understand whichever direction is taken.
I would love to hear if anyone else has thoughts on this.
Interesting topic. I don’t think we’ve encountered this, but we almost never allow more than one person per registration. If we did, I don’t think we would on an event that included a waitlist.
I see three options:
If the next registration on the waitlist has multiple people, Livewhale could register one of them when a spot opens up. This would require clear communication to the registrant that they are only being registered for one person until more spots open up. They may also be given the option to pass the spot to the next available registrant and wait until enough spots open up. This would accommodate true first-come first-served expectations.
Livewhale could restrict “one person per registration” in waitlist situations. Users who want to waitlist multiple people would just have to submit multiple registrations. This would avoid conflicts altogether.
Change the behavior as Sejr suggested and add a message when someone selects multiple people for a waitlist registration that warns them that groups can only be accommodated if enough slots open at the same time. Openings will go to the first waitlisted registrant that can be accommodated. This puts the choice on the user.
Regardless, this feels wrong:
I can’t think of any scenario where users on a waitlist should be ignored and spots opened for the public.
Thank you for the thoughtful discussion here. In our next minor release, we’ll be updating how waitlists function to address the situation outlined in this thread.
In short, once the release is live, any new RSVPs will automatically be added to the end of the waitlist whenever a waitlist already exists. (This closes the current edge-case loophole where someone might “sneak in” to an open registered spot, if the waitlist were to be “clogged” by a multi-person registration awaiting more seats to open up.)
One implication is that you could approach the day of your event with 29 of 30 spots filled while the first person on the waitlist is holding out for two seats, even though others farther down may only need one. Rather than introducing automated logic to skip ahead in these cases, we’re intentionally leaving that flexibility with event organizers. For example, you might choose to contact the first person on the waitlist to see whether a single seat would work for them.
Otherwise, the waitlist will continue to operate as it does today: whenever an RSVP is canceled and enough seats become available, registrations will be confirmed from the top of the waitlist in order.
Please let me know if I can clarify anything further, and thanks again for the helpful feedback!