Scot McConnachie
My feedback
133 results found
-
8 votes
An error occurred while saving the comment -
27 votesScot McConnachie
supported this idea
·
-
66 votesScot McConnachie
supported this idea
·
-
78 votes
An error occurred while saving the comment Scot McConnachie
commented
I agree with the previous post: allow an arbitrary set of assigned resources be assigned to each session in an event. Linking resources to an event could be an option. If the event session itself is rescheduled then probably the linked to resources should be released and the new session time would have its resources linked in, depending upon availability.
Scot McConnachie
supported this idea
·
An error occurred while saving the comment Scot McConnachie
commented
I would suggest extending this concept to a "resource reservation module" so that any fixed resource could reserved. Then the administrator could define the resource as a room, an overhead projector, whatever. For resources with capacity usage limits, such as the number of people, that capacity could be listed in a user defined field.
-
6 votes
An error occurred while saving the comment Scot McConnachie
commented
For this to really work, contacts should be required to set up login credentials in order to register for an event. Otherwise, it could be easier for a non-member to register for event than for a member to do so.
We have a policy to bifurcate our event registrations between members and non-members: we invite a limited number of the public to be guests at large of the organization or the group of members hosting the event, rather than as the particular guest of an identified member. This is to encourage non-members to participate in organization activities, thereby encouraging them to become members.
The only way that we can do that now is to offer both a Members registration type and an Everyone registration type. Then we have to beg members to register using the Members registration type. This is an awkward request, partly because we have to put the request in writing that the member not use the Everyone membership type, and also because members have to login to their accounts while non-members don't have to login in order to register for the event.
A non-member registration type would best be set up to require that the registrant either has login credentials and must use them to register for the event, or for a new contact, they must create those credentials at the time of registering for the event.
This would be a very useful feature for any organization that wishes to include a limited number of at-large persons from the public in membership events.
Scot McConnachie
supported this idea
·
-
6 votesScot McConnachie
supported this idea
·
-
255 votes
An error occurred while saving the comment Scot McConnachie
commented
Since there currently is no means of members having an ability to edit just their own complex events, we decided to use the honor system to encourage members to not edit others’ evens. We started to give them all Event Manager privileges....until we realized that the Event Manager could see all contacts, the detailed financial data of all members, and all of our organization summary financial reports. That was way too much information!
The granularity of administrative functions needs to be drastically increased. Since this granularity defines workflows it is a higher priority than most users realize.
An error occurred while saving the comment Scot McConnachie
commented
A few thoughts about delegated administrative roles:
Within each general administrative role there are specific features which involve viewing/creating/editing/deleting data on the system. Within that data I see a distinction between data that is common service data (contacts data, membership data, system settings, financial settings, system email templates) and other data, which I will refer to as content data.
Common service data would include all data that would not qualify as a specific communication or service by the organization.
Content data is the complement of common service data: it includes communicating and providing the services offered by the organization. Content data would include web pages, email blasts, forums, donations, blog entries, RSS feeds, the forthcoming store, and events.
Each feature in an administrative role allows for viewing/creating/editing/deleting data. A feature might be a single field or function (for example, a visibility setting) or a set of fields or functions (for examples, the details of an event or the details of an event registration type). Viewing the data might be a default that comes with the role, but there might be some exceptions.
This brings up what I call scope: the area of viewing and control for a (delegated) role or feature.
In the case of common service data, the scope would be limited to the categories defined within the role’s area of responsibility. For example, the scope of a delegated finance manager could limited to accounts receivable or other types of reports. A delegated group manager might be prevented from creating new groups but could edit members within the selected groups under the control of that manager.
Content data would have an additional parameter to scope: to limit the administrator’s ability to view/create/edit/delete content generated by that administrator or by other administrators. For example, a donation drive, web page, email manager, forum manager, or an event manager could be limited to viewing, creating, editing, and deleting
• just the content generated by that manager personally,
• the content generated by managers within a membership level,
• the content generated by the managers within a group,
• or have full access to all content within that role.With such granularity of permissions and a few tweaks to the existing feature sets, it would be possible to create implicit simple workflows for organization content data without having to program them in. To provide an implicit workflow to such editing, each set of data (an event, a donation drive, a web page, a forum category/forum area/forum thread, an email blast) would have a view restriction feature that could be switched between Admin, Restricted (to groups or membership levels), or Public. For example, by restricting a delegated administrator’s content to Admin only visibility means that some other administrator, who could see and edit the content, would have to authorize the set of data for a higher level of visibility. Similarly, restricting the visibility of that administrator’s content to the members of a group would allow peer review by that group (some of whom might not be administrators) before the content is made visible to full sets of members or to the public.
Implicit in such a scheme is that there always exists somewhere at least one administrator with full access to the entire administrator role. Also implicit is that the current number limits on administrators would not exist. Allocating delegated administrators could be limited to administrators who have been granted full access to a role or to full system level administrators.
For example, a full donations manager could delegate to a system user the ability to create and manage a donation drive. In setting up that drive the now delegated donation manager could be given access to a limited set of web pages at start to set up the donation. After viewing and removing the visibility restrictions on the new drive’s web page and donation settings, the full donation manager could give the delegated donation manager access to specific saved searches for sending out email blasts, as well view/edit access to the financial record keeping for that drive. Here I used donations as an example of how delegated roles might work; our primary interest is in events. In our case we have a need for an events manager role to be delegated down to the level of the event organizer, who in our case could be any or every member of our organization.
Delegating administrative roles empowers the membership, allowing them to generate the content that best serves to promote the organization. Empowering the members to self-organize their administration and the creation of content actually becomes a new service (content, if you will) that the organization can offer to its members. To borrow from a Canadian of note, the Wild Apricot medium itself would become the massage.
An error occurred while saving the comment Scot McConnachie
commented
I also agree that the existing limits on the number of administrators are too few in number but, if this number were increased, too many admins would have too much power. One question that I will ask, and for which in fairness I don’t expect Wild Apricot to answer publicly, is does Wild Apricot actually need a limit on the number of administrators when there already exists another parameter, the number of contacts, for moving an account up to the next pricing tier?
For an organization to grow organically it needs to rely upon its members’ contributions from below and that means empowering the members with some of the powers currently held by system administrators. The lesser powers could be assigned to individuals, to groups, or to membership levels. In our case we would want essentially all of our members to have the power to create most details of an event and for some trusted members we probably could let them create all of the details of an event.
I also point out that limits on the number of people with administrative authority is affecting how users come up with proposals on the Wishlist. For example the current proposal for allowing members to create their own events is at least partly an attempt to circumvent limits that were placed on the number of administrators.
Scot McConnachie
supported this idea
·
-
102 votesScot McConnachie
supported this idea
·
-
5 votesScot McConnachie
shared this idea
·
-
13 votesScot McConnachie
supported this idea
·
An error occurred while saving the comment Scot McConnachie
commented
We also limit free event attendance to guests of members using a monthly inventory based upon membership level.
-
200 votes
An error occurred while saving the comment Scot McConnachie
commented
One more addition to my previous message:
1) i. A preset list of hashtags available for assigning to the event.
An error occurred while saving the comment Scot McConnachie
commented
An admin asked me to repost this message from the following topic:
It is posted here in a slightly edited form. Our organization hosts many events with recurring sessions that, on a limited basis, are open to the public, so we found the proposal in the above link to be too limited. Our typical events will have free registration options for members and the public, the latter of which are constricted by the member event organizer’s Membership Level. In effect, the public attendees are “guests at-large” of the event organizer and can self-register into the event (the organizer, when a member, can also register specific guests as well). We use bifurcated event registrations, to members or the public, as a primary recruiting and retention method for our organization.
1) This proposal is to extend the administrator paradigm by giving a contact (not just a member) Limited Event administrator access to the Administrative View of the organization website. I propose the following options for setting up each Limited Event Administrator.
a. To view or not view but not edit others’ events in the Event List (or a calendar UI). This allows one to see potential event conflicts. See item 3) below for more options.
b. Allowing specific Visibility (i.e. Event Access) settings when creating and editing one’s events. For example, if a Limited Event administrator is restricted to creating Admin Only visibility events then that creates an implicit workflow where that administrator must have de facto approval to change Visibility.
c. A numerical limit on the total number of attendees in an event (no limit is possible).
d. A numerical limit to the total number of future event sessions on the system at any time (no limit is possible).
e. A preset list of Saved Searches that may be chosen from to announce an event.
i. As a sub-option, limits on the number of announcements to reduce “spamming” effects on the recipients.
f. Whether the administrator can create RSVP events, Regular events, or both.
g. For Regular events I see the following Limited Event administrator options.
i. Similar to item 1) b. above, restrict to specific Visibility (i.e. Event Access) settings for Regular events. Because Regular events are more complicated, it is a reasonable control to separate this setting from RSVP events.
ii. A different preset list of Saved Searches that may be chosen from to announce the event. Why is this a different list of saved searches from RSVP events? Because RSVP events cannot have a separate registration limit for the public versus members. If an RSVP event is open to the public, then the organization loses control over how many public members would be admitted to the event. This might be acceptable to many organizations, particularly when they can charge admission to the event. However, for us we have to ration public access differently since our competitors offer free events: we do this using membership dues. Since we have to ration public access differently, it is very likely that our RSVP events would be members only; we would not want to announce such events to the public.
iii. Across all Event Registration Types, set a maximum allowed price ($0.00 is possible; no limit is also possible).
iv. Across all Event Registration Types, set a minimum allowed price ($0.00 is possible).
v. Across all Event Registration Types open to the public, limit the number of non-members allowed to register (0 is possible, which would negate public access; no limit is also possible).
vi. Across all Event Registration Types open to the public, set a minimum price ($0.00 is possible).
vii. Across all Event Registration Types, set a maximum number of guests allowed per registrant (0 is possible; no limit is also possible).
h. Allow the Limited Event administrator to exceed any or all of the limits set above, but highlight the exceeded limits in red (or some fashion). The system would retain an event that exceeds its author’s limits but it could not leave Admin Only status, nor accept registrations, nor be announced by email blast: only a higher level administrator could make these changes. This would provide an implicit workflow.
2) The Calendar interface in the linked to topic is a great idea: event administrators need it too.
a. Calendar events could be coded by their Visibility and/or Open to Registration status.
3) There is more that could be done with the scope of events that a Limited Administrator could view or edit, such as
a. Events by chapter.
b. Events by administrators within a membership group.
c. Events by administrators within a membership level.
d. Events by hashtag.
Giving members backend access to their events becomes a natural way to recruit them as eventual administrators and officers.
An error occurred while saving the comment Scot McConnachie
commented
I want to give this right to the majority of our members so the limits on some types of administrators would also have to be relaxed.
Scot McConnachie
supported this idea
·
-
267 votes
Dmitry Smirnov
responded
Even though it is not a direct implementation, I hope this could be helpful:
We just launched integration with Integromat platform, which helps to build automated workflows. We also provide several templates for quick start, and one of them allows to copy google calendar events into WA events. So if you share a google calendar for events submission, then the scenario could copy submitted events into your Wild Apricot account.
You can try this integration by this link https://www.integromat.com/en/integration/2275-copy-google-calendar-into-wild-apricot-eventsAn error occurred while saving the comment Scot McConnachie
commented
Done. Thank you for your attention.
An error occurred while saving the comment Scot McConnachie
commented
Our organization hosts many events with recurring sessions that, on a limited basis, are open to the public. Our typical event will have free registration options for members and the public, the latter of which are constricted by the member event organizer’s Membership Level. In effect, the public attendees are “guests at-large” of the event organizer and can self-register into the event (the organizer, when a member, can also register specific guests as well). Bifurcated event registrations, members or the public, serve as a recruiting tool for new members and, since admitting the public helps events to achieve the necessary critical mass of participants, as a retention tool for existing members. As most of our member-generated events are Regular events, I see little benefit to our organization from the current proposal.
1) Under Wild Apricot’s current proposal, the ability to submit events can be assigned to an individual member. In effect that member would be a Limited Event administrator with editing privileges only over the events that member creates. That’s great so far. Rather than creating an entirely new interface for the member’s Profile, instead I suggest extending that administrator paradigm by giving a contact (not just a member) Limited Event administrator access to the Administrative View of the organization website. I propose the following options for setting up each Limited Event Administrator.
a. To view or not view but not edit others’ events in the Event List (or a calendar UI). This allows one to see potential event conflicts.
b. Allowing specific Visibility (i.e. Event Access) settings when creating and editing one’s events. For example, if a Limited Event administrator is restricted to creating Admin Only visibility events then that creates an implicit workflow where that administrator must have de facto approval to change Visibility.
c. A numerical limit on the total number of attendees in an event (no limit is possible).
d. A numerical limit to the total number of future event sessions on the system at any time (no limit is possible).
e. A preset list of Saved Searches that may be used to announce an event.
i. As a sub-option, limits on the number of announcements to reduce “spamming” effects on the recipients.
f. The ability to create/edit/delete Regular events in addition to RSVP events. For Regular events I see the following Limited Event administrator options.
i. Similar to item 1) b. above, restrict to specific Visibility (i.e. Event Access) settings for Regular events. Because Regular events are more complicated, it is reasonable to separate this setting from RSVP events.
ii. A different preset list of Saved Searches that may be used to announce the event. Why is this a different list of saved searches from RSVP events? Because RSVP events cannot have a separate registration limit for the public versus members. If an RSVP event is open to the public, then the organization loses control over how many public members would be admitted to the event. This might be acceptable to some organizations, particularly when they can charge admission to the event. However, for us we have to ration public access differently since our competitors offer free events. Frankly, RSVP events aren’t very useful to us.
• Alternately, have an option to restrict a Limited Event administrator to submitting Regular events only.iii. Across all Event Registration Types, set a maximum allowed price ($0.00 is possible; no limit is also possible).
iv. Across all Event Registration Types, set a minimum allowed price ($0.00 is possible).
v. Across all Event Registration Types open to the public, limit the number of participants allowed to register (0 is possible, negating public access; no limit is also possible).
vi. Across all Event Registration Types, set a minimum price for types open to the public ($0.00 is possible).
vii. Across all Event Registration Types, set a maximum number of guests allowed per registrant (0 is possible; no limit is also possible).
g. Allow the Limited Event administrator to exceed any or all of the limits set above, but highlight the exceeded limits in red (or some fashion). The system would retain an event that exceeds its author’s limits but it could not leave Admin Only status, nor accept registrations, nor be announced by email blast: only a higher level administrator could make these changes. This would provide an implicit workflow.2) The Calendar interface is a great idea: event administrators need it too.
a. Calendar events could be coded by their Visibility and/or Open to Registration status.
I fear that the current proposal by WA is going to put event creation into a workflow rabbit hole that will be increasingly divorced from what it is really is: a part of the organization’s administration. It is in most organizations’ interest to empower members from the ground up to serve as potential administrators. Let the members see the backend.
An error occurred while saving the comment Scot McConnachie
commented
As I am increasingly being influenced by this proposal elsewhere on the Wishlist:
I thought that I would experiment here with what the approaches being considered in that proposal would look like with events created by members.
These ideas are based on the hypothesis that everyone potentially has full administrative access to the events module but in reality the organization will restrict that access to meet the organization’s specific management requirements. In principle, everything below would be giving members limited access to the administrative backend.
First, allow events to have a proposed status where they are not yet scheduled into a space-time location. Meetup does this. System users can still register for the proposed event but will have to recommit to the event once it is scheduled. Proposed events can be shown on the calendar gadget. All registration types might have to allow a proposed status followed by a confirmed status in their settings. This is to allow, but not require, the event workflow to start with the membership.
Sets of event information can be saved as an event template which can be instantiated when an event is created. This is to allow administrative control, and standardization of event UIs and data inputs. Meetup just inaugurated this concept in Meetup Pro.
Allow system users, contacts or members, a limited set of administrative roles below the full the administrative event manager role and allow the members access to a limited form of administrative mode to create, edit, and delete events.
The administrative scope of such sub-roles can be limited to read only/create/edit/delete events that are
1) Organized by an individual contact. This is new and many organizations would not want this but my response is that some organizations will want to empower contacts in some ways in order to a) collect revenue from their efforts and b) to induce them into becoming members. It is my personal belief that contacts should be treated as a full system user level below members but that is a separate proposal.
2) Organized by an individual member.
3) Organized by members within the same membership group.
4) Organized by members within a membership level.
5) Later, organized within a chapter.
6) Later, organized within a network of chapters.
Below full administrative control, sub-functions associated with events can be assigned:
1) The ability to propose/create/edit/delete events.
2) Whether an event created by this use requires higher administrative approval to be placed on the schedule as either
a. A proposed event.
b. The actual event itself.
3) Whether the user has the ability to approve another user’s event within one of the above specified administrative scopes.
4) The ability to set event tags for the event, use a defined subset of preset tags, or only one preset tag. In my view there is still need for a central event tag manager at the full administrator level. The event tag feature is a surprisingly powerful feature of Wild Apricot.
5) An adjustable contacts/members access control for sending email invitations to prospective registrants. This can be full access to contacts and searches down to limiting access to zero or more pre-designated saved searches. Later, if social network posting becomes a reality, there would be controls for allowing access to post event invitations to preset social network channels (Facebook, Linked In, etc.)
6) An adjustable access control for allowing users with sub-administrative privileges to overwrite standard email templates used for announcing, registering, and confirming the event.
7) An adjustable access control for allowing members with sub-administrative privileges to set capacity constraints and registration types for the event. For lower access controls, possibly the potential event class described above, and possibly later (if social posting of events on Facebook and Meetup becomes a reality) for registration types that map into social network events, the event might have one or more pre-fixed registration types.
8) One or more event templates can be assigned to certain levels of control.
9) Later, events could be limited to a preset list of venues.
10) Later, events could be assigned to bookable resources.
A subset of these administrative roles and scope can be assigned to individual members, members of a group, or to members of a membership level.This is not a trivial set of ideas but most of the UI for these controls amount to managed subsets of the existing controls available at the event manager administrative level.
Events are the heart of what an organization does. With the possible exception of serving as a repository of information for members, events are the primary reason why organizations exist. Events work best if they percolate up from the membership.
An error occurred while saving the comment Scot McConnachie
commented
A few more comments:
1) There need to be more fields than the ones proposed even if this is a first pass at a solution to the problem. Using the information presented under the current proposal if an event is submitted the administrator would still know nothing about the planned fee structure, attendance, or space requirements for the proposed event.
2) Part of why a member will put forward an event is to recruit potential participants and to judge interest in the event. I would suggest allowing such proposed events to have visibility to the membership and to allow members to quickly indicate their interest in such an event, even if this interest does not constitute a formal registration in the event. Going further I would allow the organizer the ability to send an email message to those parties interested in the potential event: scheduling happens not just on the administrator side but on the members' side as well.
I say these comments knowing that this is a first pass at the problem, and matters such as workflow and setting registration levels will be addressed in a later version. My long term advice is to figure out a way to map events and certain event registration levels into Meetup or to socialize Wild Apricot similar to how Meetup copied what Facebook did.
In the long run your competition is not ClubExpress, Tendenci, or MemberClicks....it's Meetup.
An error occurred while saving the comment Scot McConnachie
commented
I just looked at current design outline (dated February 12, 2016). Under item "1) Restricting submitting events option to specific members" I have one more suggestion:
Please provide an option to allow restricting submitting events to the bundle manager only.
In our organization we use bundle managers as "group host members" and they have more privileges than the members of their group (i.e. bundle).
An error occurred while saving the comment Scot McConnachie
commented
One more thought regarding data entry validation: as an option allow administrators to create a predefined list of allowed venues.
An error occurred while saving the comment Scot McConnachie
commented
Automatically assigning tags is a very good addition as administrators can do a lot with simple tag assignments. However I do think that you need more data entry validation on the member event submission forms:
1) I would look at allowing administrators to define fields associated with events, just as you do with contacts/members. Similarly I would allow a pop-up lists/check boxes, etc. to be set up for these fields.
2) Similarly I would allow for pop-up lists/checkboxes that would map directly to preset tags. I would do this particularly if your reject my proposal 1) above. At least the existing tag field could be used to hold a significant amount of information.
3) More importantly I suggest allowing administrators to restrict the dates and times on the calendar UI itself to one or more sets of date and times with each set of dates and times being associated with a unique tag as defined by an administrator.
Our conference hosts 400 event sessions in three days. Each event happens in one of five departments and all events use a cross-convention time block system to regularize how our members schedule their activities. Each time block and department has a program code.
It's too bad that you are delaying the approval workflow but this is still tremendous progress!
Scot McConnachie
supported this idea
·
An error occurred while saving the comment Scot McConnachie
commented
While organizers/administrators may have a common idea of what they mean when the they set up an event, when you start taking information from the members you can no longer rely on a common set of an assumptions about what constitutes an event. Also there can be a lot of supporting information surrounding an event and that information can be unique to each organization or event.
We run 3-day conferences that host 400+ event sessions at the conference (you might call our events "sub-events" as by registering for the conference one then becomes eligible to host events and to register for the events at the conference). Almost all of the events at the conference are submitted to us by our members, and are reviewed, edited and approved by administrators. For organizations such as ours to consider using your system at our conference we would need the following features:
1) An event approval workflow along the lines you outlined above where the control over the content eventually transfers to an administrator, after which the member can propose changes or cancellations but they are signed off by an administrator. I would hope that a Wild Apricot workflow would be designed to be more flexible than what I have described above but that this would be one option that we could choose within the set of workflow options that WA would provide. I would also hope that such a workflow would allow for a log of changes and for a listing of internal comments associated with an event proposal, similar to what you have for invoicing.
2) At our largest conference we have found it necessary to organize our events into departments, standardized time blocks (which are the same across departments), and sub-categories of event type. Thus we are typically displaying events by departments (we call them Event Areas) and time blocks both in our program and online. Currently the only way that we would add such data to an event using the Wild Apricot system would be to use the existing meta-tag system with carefully designed tags and event calendar gadgets carefully designed to capture events with particular matching tags. However there is a problem here: under the current proposal no tags are visible to the person proposing the event, nor is the meaning of the tag apparent. For this problem I am proposing that we allow administrators to define a user interface for the members' event proposal form where there are preset options to add predefined meta-tags to the tag field.
3) Frankly, adding an administrator controlled member UI to meta-tags would not be enough. In addition to having administrator presets for the tags behind an event proposal form we would also need options for administrators to define data entry options for both existing (time, date, location, description) and new (administrator-defined) data fields that could be presented in the event proposal form itself. Similar to what you have with contact and member administration, we need to be able to define additional event fields and a user interface for these fields that can be used to enter data into, validate, and to display information from events. Similar to what you have for contacts and members, we could use advanced search and saved search options for events.
4) Member submitted events can have their own management problems generated by the sheer number of events submitted. To treat our members fairly we sometimes have to ration access to events such as by letting out a fixed percentage of slots at certain times while releasing the rest on-site so that our more recent registrants can atttend at least some of the events at these conference. To manage these controls on an event by event basis at one of our conferences would be a nightmare. With at least admission limits there is a need to proration numerical values at one time across whole searched for sets of events as a part of the administrator user interface. I can also see non-prorationed adjustments of field values across sets of events with the same properties such as time, location, etc.
5) Finally, not all events are the same, some are sub-events of a larger event. Currently we can get around this problem by incorporating our super-event registration at the membership level (for example certain membership levels include an implicit super-event registration; only those levels of membership can see or register for an event at this super-event) but this would become messy once we offer a second conference similar to our largest one. I recommend looking at conferences as super-events or at least as sets of events that employ a common set of properties that can be predefined by an administrator. -
3 votes
An error occurred while saving the comment Scot McConnachie
commented
My understanding is that email announcement and reminder settings are copied into a duplicated event if the copied event is in the future but not if the copied event has already happened. The Wild Apricot developers are aware of this issue.
See
-
12 votesScot McConnachie
supported this idea
·
-
10 votesScot McConnachie
supported this idea
·
An error occurred while saving the comment Scot McConnachie
commented
I agree that events need custom fields for a variety of reasons. In general, different organizations are going to have different criteria for organizing their events.
In our case for example we have event departments, program numbers, event presenters, publishers, event difficulty and more types of specific information about events. Events are still not first class citizens in WA.
-
13 votes
An error occurred while saving the comment Scot McConnachie
commented
Is there any progress on this matter?
With most of our members on monthly memberships and limited staff, many are routinely technically in arrears. One we way we get members in arrears to pay is to get them to keep participating in events. Now I have people who believe that they are members who can't sign up as members. The other alternative is that the system tells them that they have renewed, even though they have not paid the dues, which further adds to the confusion.
Seriously, this is a disaster that might force us to stop using Wild Apricot.
An error occurred while saving the comment Scot McConnachie
commented
I appreciate that the current (apparently new revised procedure) works for many organizations.
Here is another life example. We have limited staff and 40% of our members mostly pay on time by check. However we don't process the checks until the second Saturday of the month, partly as a grace period, partly to simplify the the accounting to once a month, and partly to allow the mail to arrive at our PO Box mailing address. We don't have someone to process checks on a daily basis. Under the current system we either have to live with activating all members, regardless of their underlying financial status, or deal with complaints by members that they paid but cannot register for events.
There should be an administrative level toggle to turn this feature on or off. I don't care if the default is on so long as we can turn it off.
An error occurred while saving the comment Scot McConnachie
commented
We ran into this recently as well, as we have been starting to use the events system more.
Furthermore our accounting meeting for the month is after the first so, for non-electronic payments, the records are not updated at the beginning of the month. The system will show an account that is in arrears even though we have received payment. That means that 40% of our membership could be in this state for as long as two weeks.
It is not reasonable to expect our staff to update the records manually to active every month.
Scot McConnachie
supported this idea
·
-
275 votes
Evgeny Zaritovskiy
responded
Please review results of our analysis and design:
https://docs.google.com/presentation/d/1aBh3RKOIAbC-YOkpQtRJ8kv9kH3ZlXSID7Ezl1bCAlg/pub?start=false&loop=false&delayms=3000Post your comments/ideas right here. Until we see major disapproval, this is what we will develop in one of future releases.
An error occurred while saving the comment Scot McConnachie
commented
I would also add that putting all such communications into a mobile app does nothing to show our organization's vitality to potential members who will be looking at our organization on the web.
Relying on an app that those parties will not install or cannot use simply creates a barrier to entry.
An error occurred while saving the comment Scot McConnachie
commented
This remains a high priority for us as well. The difference between responding to a forum notification and responding to an email thread in an email client is the difference between night and day.
We are having to use clumsy email threads (which is a two or three step process, since doing this means getting everyone's permission to disclose their email address to everyone else) to maintain communications and organizing within our organization. We have been pushing the forums recently but they remain pretty dead; the action is in the emails.
Scot McConnachie
supported this idea
·
An error occurred while saving the comment Scot McConnachie
commented
Just putting my two cents in on the need for this as well.
Every time we have had a new web developer offer his services for the group he has put in forums, the forums have died, and we have gone back to using Yahoo! Groups listservs. This has happened three times now. After this latest failure we may be looking at Meetup. To maintain interest in our organization we need push content where the end user can decide the terms of his participation. If the content is not in front of him in his email notification he will not be sufficiently intrigued to participate in the discussion; he also usually won't participate if he can't respond by hitting the reply button.
-
44 votesScot McConnachie
supported this idea
·
-
25 votesScot McConnachie
supported this idea
·
-
11 votesScot McConnachie
supported this idea
·
Also, to suspend a membership at a fixed date in advance.