Scot McConnachie
My feedback
135 results found
-
11 votesScot McConnachie
supported this idea
·
-
11 votesScot McConnachie
supported this idea
·
-
29 votesScot McConnachie
supported this idea
·
-
40 votes
An error occurred while saving the comment Scot McConnachie
supported this idea
·
-
54 votesWork in progress ·
AdminKatya Tyukina
(Director of Product Management, Wild Apricot by Personify)
responded
Great news! We have added waitlist cancellation options to our mobile app Wild Apricot for Members. The logic follows the same rules as for regular registrations. If cancellation is available for the ticket type, it will also be available for the waitlist.
We're looking into bringing this feature to our web app too. Stay tuned for updates and Happy Holidays!
Scot McConnachie
supported this idea
·
-
14 votesScot McConnachie
supported this idea
·
-
30 votesScot McConnachie
supported this idea
·
-
19 votesScot McConnachie
supported this idea
·
An error occurred while saving the comment Scot McConnachie
commented
I am totally supportive of this idea. Since half the work seems to have already been done on the event reminders this would seem to be a fairly simple improvement to implement.
It is already possible to register for a multi-session event after the first session, so continuing to announce the availability of such sessions after the starting date would be worthwhile. Many of our events are built around a core group of people who are constantly looking to have others join them.
One option could be to allow the announcement blasts to stop if the event is fully registered, and resume if slots open up due to cancelations, but I would set these as an options only.
-
9 votesScot McConnachie
supported this idea
·
An error occurred while saving the comment Scot McConnachie
commented
We have similar situation in which different membership levels have different guesting privileges. While our situation is probably more complex, the number of guests is a per month function, being able to map this ability into events would still be useful to us.
-
105 votesScot McConnachie
supported this idea
·
-
45 votesScot McConnachie
supported this idea
·
-
1 voteScot McConnachie
shared this idea
·
-
13 votes
An error occurred while saving the comment Scot McConnachie
commented
Some organizations will want to charge interest on past due membership bills. This is commonly 1% to 1.5 % per month past due.
Having this interest automatically calculated into past due invoices would be a useful feature.
An error occurred while saving the comment Scot McConnachie
commented
Due to a failure to understand how the current system works I am now having to go back and retroactively bill a number of our members who failed to pay their earlier bills and therefore were never invoiced for their later bills. They are not going to be happy and I am probably going to have to cut deals in some cases.
I should add that this is a pretty basic function of many membership organizations, including several golf clubs and athletic clubs that I have been a member of. Opting out is a process that is not defined by the member's decision simply not to pay.
I argue that this function is more essential than is suggested by the lack of attention that this proposal is receiving from other wishlist viewers. Self-selection may be at play here: organizations that have this function as a requirement may not be using Wild Apricot because this opt out function was not found during their evaluation of the software.
An error occurred while saving the comment Scot McConnachie
commented
A couple more comments:
1) Some organizations might allow partial payments on outstanding invoices as part of a settlement plan.
2) Some organizations might want the actual "opt out" process to be automated within Wild Apricot. One way to do this would be to add a toggle to a membership level that would allow the organization to state its formal opt out language and allow the member to push a button indicating that the member is exercising his/her/their right to depart the organization. Depending on the organization's rules the result of pressing the opt out button could be "hard" or "soft". The "hard" result would be that the membership is immediately suspended by the member's own action. The "soft" result would handle situations where the organization's rules or contracts do not allow an immediate departure by the member, such as when confirmation by a membership committee or a secretary is required. In the "soft" opt out case the membership account would be flagged as requesting a suspension, an administrator would be notified of the suspension request, an administrator would be required to actually suspend the account, and, upon suspending the account, a notice of suspension could be sent to either the now former member or other administrators. This "soft" approach would allow an alternate means to communicate a requested opt out rather than using formal mail, email, or a telephone call.
An error occurred while saving the comment Scot McConnachie
commented
Yes, that is the gist of the proposal. Plus some ways of limiting the number of periods this invoicing will continue.
Scot McConnachie
shared this idea
·
-
32 votesScot McConnachie
supported this idea
·
-
10 votes
An error occurred while saving the comment Scot McConnachie
commented
For what it is worth, our organization uses the term "Group Host" for a bundle administrator but obviously this would not be universally applicable, nor it is supported on the system itself.
It would be nice if Wild Apricot allowed mapping organization specific terms for certain system terms.
-
40 votes
Dmitry Smirnov
responded
We are going to include it into our next year plan.
An error occurred while saving the comment Scot McConnachie
commented
5) If a registrant changes her/his/their registration status their forum subscription status would change accordingly.
Scot McConnachie
supported this idea
·
An error occurred while saving the comment Scot McConnachie
commented
This proposal is to provide a degree of integration between events and forums.
When an event is created include an option to create a forum thread associated with that event.
1) A hyperlink to the forum would become a part of the event's page or embedded in the event's description.
2) The event organizer would be subscribed to the forum as a moderator.
3) Subject to the visibility of the forum thread, registrants to the event would be subscribed to the forum. If the forum is visible to the public then a setting would allow either all attendees to be subscribed to the forum or the subscription could be limited to exclude non-members, members of particular levels, and/or guests. If the forum has less visibility than public then those registrants outside the event's visibility would be automatically excluded from the forum but the options would remain to exclude those registrants who are inside the forum's visibility.
3) If the event is rescheduled then the forum would receive notification of the new date and its header would indicate the rescheduled date and update its header accordingly.
4) If the event is deleted (since 'canceled' is not currently an event state, which come to think of it, it should be) then the forum would receive notification of the 'cancelation' and its header would be updated accordingly.
Most of our events are organized at the grass roots rather than serve as formal occasions. Discussion and participation among the registrants actually adds to the content of the event, to the sense of community among our members, and, when posted on a publicly visible forum, will greatly serve to excite prospective members toward joining our organization (especially when listserv makes the forums themselves vital).
-
8 votesScot McConnachie
supported this idea
·
-
311 votes
Evgeny Zaritovskiy
responded
Collecting comments now.
An error occurred while saving the comment Scot McConnachie
commented
I would like to see two choices for this feature:
1) Each session accepts an entirely new set of registrants.
2) Each session is open to new registrants but carries over the registrants from previous sessions.
A number of our events are organized around of group of core attendees who make the event viable but also very much want others to join them, which is why we would like the second option above.
Scot McConnachie
supported this idea
·
-
18 votes
An error occurred while saving the comment Scot McConnachie
commented
This is especially desirable since we do not yet have the ability to allow registration into repeated events and therefore have to duplicate the entire event in the schedule.
Many of our events are based around a core group of attendees who very much want others join them for subsequent sessions. Currently to do that we have to duplicate the event and then duplicate the registrations, or don't bother and just assume that the regulars will be in attendance.
Scot McConnachie
supported this idea
·
-
2 votes
Team Mobile
responded
Status update in case someone new will see this topic:
The section “Show registrants who want to be listed” have been added to API already.Schedule for email announcements and reminders can’t be set via API at the moment.
As a workaround, you could create a template event on the web, set the start date in the distant future and all settings you need. Then you can clone it via POST request:
api.wildapricot.org/v2/rpc{AccountId}/CloneEvent
The request body should be like this:
{“EventId”: 123456}An error occurred while saving the comment Scot McConnachie
commented
We are currently considering utilizing the ability to create events as part of a resource scheduling application. Being able to manage email options via the API is an expectation for us.
Note that it would be possible to indirectly manage email content and scheduling for events by administratively setting up events with such settings preset and then copying them, however this is not possible for two reasons:
1) There is a bug in Wild Apricot where duplicating past events behaves differently than duplicating future events. If a future event is duplicated then the event email messages and schedules are duplicated, however if a past event is duplicated then these settings are not duplicated. This is a bug because this different behavior is not documented and does no meet reasonable user expectations.
2) The API is missing a "duplicate event" call. In my opinion it should have such a call, partly for the mobile app in addition for other potential apps.
Scot McConnachie
supported this idea
·
Yes, with event showing up in the calendars of these social media.