Bringing up Enrollment Questions - AGAIN...Sorry, kids!

EthosCE Product Suggestions Course administration
1

I have yet another question about enrollment questions. This is similar to what JAM wrote about last July.

We use enrollment questions for breakout sessions at a couple of our live courses. Enrollment questions are great for tracking people’s choices via the Enrollments .csv report, which is why we use them; however, we usually have limited space for breakouts and need to set enrollment caps. We currently have no way to remove a breakout from the list of options once it’s full. We put language on the breakout indicating that it’s full but some people, being what they are, still sign up for full sessions (probably hoping to get in on-site).

It would be nice to have a way to ‘gray out’ a breakout and remove its radio button to block enrollments. Is anyone else interested in being able to do this? We absolutely won’t use a parent-child setup for these meetings–that’s 'way too complicated.

There has to be a solution somewhere.

2

If we could associate a fee to enrollment questions, then I’d be interested in something like this. I do use the parent-child set-up because we mostly charge for breakouts/workshops and HAVE to cap them (way too many to track manually). So to have people select a workshop in enrollment questions and then have to select them again to pay won’t work for us. We’d need a solution that both caps enrollments and can charge a fee.

3

Having a maximum in an attribute would be good (you can already charge a fee for an attribute option). Just a thought that would be a solve to this request.

2 Likes
4

I agree!

We regularly create attributes to track and charge for workshops etc. We have had to manually remove attribute options when the maximum capacity is reached.

5

We have the same thing when we use attributes for Exhibitors. We only have so many tables at a course that they can use. We have to manually alter those options within the attributes to show that they are sold out.

6

We shy away from using attributes because it’s so much harder to track specific people’s selections (the orders report dumps everything into one cell in the worksheet–it’s a heinous task to break all that out). Plus, I can make the enrollment questions pretty and break them up into tabs by day for the multi-day meetings, which is very popular around here, AND we never charge for breakouts so we don’t need the financial aspect of the attribute option.

In our case enrollment questions are the best option, overall. One meeting has always provided a personalized itinerary for attendees, and using enrollment questions has saved the coordinator of that meeting many hours of manual work digging through the orders report for attribute information.That’s where my whole off-label use of enrollment questions started four years ago.

It sounds like to some extent it’s a wash–either you can easily track breakouts via enrollment questions or you can charge money and place caps on numbers using attributes. There isn’t a happy medium anywhere that I can find.

7

We have started to use our own education data warehouse and wrote a report that broke out the Attributes into different columns of a spreadsheet for easy calculation. Not sure if this is going to be considered in the Looker reports.

Another issue that I found with Attributes is that we can not alter them once a choice has been made. Thus, if we have Dr. Jim noting he is not coming to the course gala, and then changes his mind and sends us a note that he wants to come and bring a guest, we can not update his choice.

</hint on> That would be a nice thing to consider for a future release </hint off>

1 Like
8

I definitely like the idea of offering an itinerary which is why I do wish either enrollment questions or attributes could be updated to provide flexibility that can serve everyone’s needs.

We deal with having to provide users their workshop selections and we go the invoice route. Though, through parent-child I can see what people selected in one spreadsheet (separate from the orders one). However, I can’t (without manipulation) use that to hand to people individually.

I think this issue is more about flexibility than it is just narrowing down to partial functionality for just certain cases.

1 Like
9

I think you’re right. The best option would be one that marries the attribute and enrollment question options, and allows us to select what we need and what we don’t.

10

(I don’t mean to pile on, however…)

So we use attributes when our breakouts have limits because (as it’s been stated) we have the option to at least manually remove a selection when it gets full which is the greater benefit to us (although yes, we would also like the option to set a cap if possible, but I think you already know that, Ezra :wink: )

That being said, there are also times when we will also have the same breakout running more than once, so we’ll have option A and B at 1pm and then again at 2pm, but have no way to keep people from signing up for option A twice (honestly, you wouldn’t think it’d be a problem, but it happens).

For awhile we were using webforms for registration because the conditionals could let us control that, but it still didn’t solve the max capacity issue, and it wasn’t as functional as the attributes for payment, and even if the breakouts didn’t require payments, we’d run into the problem of people not proceeding on to complete the breakout webform once they completed the initial registration and payment process.

That being said, I’m curious if there could be some way to apply some of the webform elements to either the attributes or enrollment questions? Or even, do something similar with the form settings as it exists in the email settings? This is going to sound convoluted, so bear with me…

In the webform ‘form settings’ there is the option to limit the number of times a user can submit the form, or even limit the total number of allowed submissions. While in the webform ‘email settings’, you can select certain component values that have been entered in order to control who the form is being emailed to, what the subject line will say, etc. But what if instead of simply limiting the number of times a form is submitted, I could select a specific component value and but a limit on THAT instead? And then essentially pulling that together with the ‘conditionals’ ability of the webform (including the easy to organize .csv file) and applying it towards the attributes and its payment capabilities?

Easy as anything I’m sure :smile: but just some thoughts.

11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.