Support

February 26, 2019 at 12:11 pm

Hi Derek,

Auto-promote: When 1 spot opens, just 1 spot is auto-promoted to payment pending, correct?

Correct.

So, if that person doesn’t complete their registration, we have to manually set them to cancel (or waitlist), then manually promote another person to give them the opportunity to finish their registration. Is this the intended process?

Correct, EE only handles registrations if the event is sold out and then a space becomes available. It will not automatically promote the next waitlist registration if you cancel the previous one it promoted.

That turns into too much work, so I decided to do it all manually and call it a ‘Notification List’ instead (so there is no priority). When 1 seat opens, I promote all attendees on the waitlist to pending payment and notify. I assumed that only the first people to complete their registration would be approved, then the remaining would automatically be put on the waitlist and the event as sold out.

Whilst the first person to pay would be approved, the remaining registrations would NOT be moved back to waitlist, once you’ve promoted them you’ve taken them out of the control of the waitlist add-on, they will continue to site at Pending Payment.

Instead, the max number of tickets increased. So the event is oversold and I have to manually demote the ones in Pending Payment to Waitlist.

The max number of tickets isn’t increase, its sill set at 12, however because you’ve set the registrations to pending payment your basically bypassing the current sold out checks for those registrations, meaning they can all pay for their ticket and increase the ‘sold’ value. Thats expected with the waitlist add-on at this time.

From the documentation:

However, if you’ve promoted multiple attendees to “Pending Payment” and only have a limited number of spaces, then the first attendees to pay will receive their spot on the “Approved” registration list.

Unfortunately, that documentation is incorrect.

Manually setting Waitlist registrations to Pending Payment allows all of those registrations to pay. Technically the first registration to pay will be approved…. but then so will the others as they pay so its incorrect.

I’ll get that documentation updated shortly.

Am I doing something wrong? Is there a better way to handle this?

The expected method is to promote only the number of registrations you wish to allow to pay.

1 – Remove the function that those on the waitlist tie up the available spaces
2 – When you move people from waitlist to Pending Payment, the spots open up for anyone to purchase the available tickets (so it’s more of a notification list, not a waitlist)
3 – Once the event becomes sold out again, automatically move those attendees back to waitlist.

Whilst I understand what you are trying to do with the above, to do so would require a major refactor of the waitlist add-on.

Whilst right now the onbly way to do it correctly is using the method you first posted (promoting a single registration, if you cancel that, manually promote another etc), it might be possible to automatically promote the ‘next’ wailist registration when you cancel the previously promoted registration.

Would that help? (Again I can’t say for sure yet but I can do some checking if it will work better for you).

February 26, 2019 at 12:56 pm

It’s easy for a user to sign up for a waitlist. However, when it comes time to actually paying for the spot, they may decide not to which I think is a reasonable reality to a lot of businesses, would you agree?

I do, but….

You cannot wait an indefinite time for someone to pay.

No-one is asking you to wait indefinitely, but the user also needs time to receive and pay for the registration, correct?

Having 1 space available and then promoting 10 users creates 9 unhappy customers, not only that it creates a new race condition because what do you do when 2 of those users register and pay at exactly the same time?

Simply put, promoting waitlist registrations from whichever state to another, is not a simple task, has many moving parts and multiple different ways in which people want to do it.

Personally (outside of EE for a minute) I wouldn’t appreciate signing up to waitlist on a class, ticket, concert, whatever because it had sold out, receive an email to sign up because hey theres a space for me and within 5 mins of receiving the email I try to pay only to see its sold out again…. that’s what your doing above with the changes your requesting.

Another solution may be to allow us to set the amount of time, in hours, in which the user has to complete their registration (or just make it 24 hours). If they don’t within that time, they their registration would be automatically be set to cancelled, then the next on the waitlist would be auto-promoted. That would remove most manual work.

Again, that sounds like a good idea, I like it, but….

The only way to do that is using WP Cron and we know from experience with using WP Cron for the message system that it causes problems for users, and host disable it, or change it, or setup alt cron incorrectly.

So again… not as simple as it seems.

If that is not possible, even maintaining the sold-out check on those registrations I think would be better, if that would stop the events from being oversold. That wait you can promote everyone over to ‘pending payment’, then it would only allow the amount of available tickets to be sold.

Yes, but I’m sure that also has its own complications, otherwise it wouldn’t have been created that way in the beginning (it’s not an oversight). I can dig into why and request some feedback as I’m not 100% sure why it works that way right now if you’d like to know, but again, there will be more underlying reasons for this than it seems.

Is any of this doable?

All of it is doable, but all of it needs to take all of the above into consideration. Seemingly small decisions have a big impact on distributed products so it’s not that I’m purposefully being awkward, there’s just more to it than meets the eye.

I realize these may be substantial changes, but the waitlist add-on seems to be a considerable amount of manual work to get the end result of selling the tickets.

I agree, for your use case you need manual work for it to work, but at the same time we can’t suit everyone’s needs straight away and as I hope I’ve made really clear above, changes need planning, we don’t just make a change and hope for the best with any of our features, add-ons etc.