Add "Applied" as a Registration Status Option
Add a status that the course leader could assign when they manually add an applicant to the roster, before they have been accepted or declined. eg. the Basic Climbing Course roster would have 300 applicants that were manually entered by the leaders. (this has the problems of communicating to applicants to create a guest account and probably too much admin burden for leaders). As students are accepted, they are moved to "offered" at which point they can pay for the course. All who aren't accepted simply remain on the "applied" roster. This would allow a quick report for following years to see who has applied multiple times.
Overall, the advantages to this "applied" status are: visibility for course leaders on who has applied multiple times; reduction of overall admin lift for course leaders running application processes; accurate data for waitlists so that we can see clearly where our pinch points are.
Becca Polglase
shared this idea
Hello All -
We are gathering information from members and volunteers that will help us with a few of our Feedback ideas, including this one! If interested, please take this 1-3 min survey to help us gather more member input to help prioritize and craft future improvements!
-
Travis Prescott
commented
This would also be useful for regular trips where permission is requested. Often time people request permission outside the website, via messenger or a separate email. This makes it hard to process permission requests fairly. If there were simply an "Applied" status in the roster when permission was requested, then at least I, as the leader, know that someone has requested permission and when they did. It would help me ensure I get back to everyone who requested permission, which I always strive to do.
Today, because it can be so challenging to track, for trips that have a lot of requests (like climbs) I require them to use a Google Form to request permission because it is exportable to a spreadsheet which has the timestamps I need. It would be great if the website did this :)
-
Kristina Ciari Tursi
commented
Sharing on behalf of Dante Di Tommaso:
Forcing "leader permission" requests, activity-by-activity, only after registration for an activity opens does not work, since activities fill up long before trip leaders are required to and do respond to requests. There are plenty ways to fix this, most of which rely on recognizing that Mountaineers Leaders have a responsibility for inclusivity as well as safety, etc. One way is to allow all members to fairly register on a first-come basis, without favoring members that have some prior relationship with a Leader. Change to "Leader permission granted" flag to "Leader permission not yet explicitly granted". The Leader can then fairly follow up with any suspect registrants.
-
Similar to Add "Permission Requested" Status, https://feedback.mountaineers.org/forums/273688-general-feedback/suggestions/44767612-add-permission-requested-status.
-
Similar to Add "Applied" as a Registration Status Option, https://feedback.mountaineers.org/forums/273688-general-feedback/suggestions/37158097-add-applied-as-a-registration-status-option-gh29.
-
Dennis Kiilerich
commented
Can we simply remove the ability to sign up for a trip that is leader's permission only and require the leader to add people?
When I've seen this happen, there's no communication at all from the participant, so it's hard to understand the context at all.
-
Travis Prescott
commented
I wonder why we don't simply add folks who request permission to the roster as a Permission Requested status instead of the current system. When I have a bunch of permission requests in my email, if I'm not thinking about it, it's very easy to process those requests in the wrong order, starting with the most recent instead of the oldest. If the were on their own section of the roster (such as with the waitlist) and sorted by request time, it would be much easier to go down the list in the right order. It would also address another issue with "Permission Request opening date" since that would just be the registration opening date since requesting permission would be a form of registration.
Also, I usually go from permission request to manually adding folks to the roster. Rarely do I reply to them and tell them to click the box and register. This flow would make it easier to do that since I would just change their status from "Permission Requested" to "Registered" or "Waitlist."
-
Joel Heidal
commented
It's hard enough dealing with the instructors and other participants that can not or will not read and understand the posting of an activity, course, field trip, ANYTHING let alone dealing with someone that registers without getting permission to do so. What is the point of having a check box or radio button if there is no functionality behind it?