[quote user="Chief_Apricot"]In next version 4.3 archived members will be able to renew. [/quote]
Woo-hoo!!! I am *very* glad to hear that. It is probably the #1 frustration for members, because they don't know what's going on and why they can't simply login and renew, and the #1 time suck for me, because I have to de-archive each person manually and write back to them explaining what happened and what they need to do.
The presence of a member's abandoned data in the archive prevents them from being able to renew and they only get a cryptic message (email address in use?) which they cannot get past. The result is that they either give up (most likely) or use a different email address or occasionally contact me and and ask what is wrong with the system. None of these alternatives is ideal or even acceptable. [/quote]
I'm glad you mentioned this; we have this problem, too. Here is a recent (and typical) email that I received from one of my archived members:
The system won't let me log in using my email address [deleted for privacy] (it says it doesn't remember my email) but when I try to do a new membership registration, it does remember me and blocks any renewal.
At a minimum, it seems as though the messages that archived members receive should be more informative, but...
For me, the ideal solution is that their membership could be automatically re-activated and their renewal date set to today's date. This is essentially what happens when I have to retrieve a member from the archive and reset the renewal date - except that I have to do it all manually and then only when the member contacts me. [/quote]
...I like the idea of an automatic reactivation, although I would not want the renewal date to be reset (again, given what I say above, that we want our members to pay their back dues).
I do agree that at some point it doesn't make sense to charge members for back dues. I guess I had thought that "lapsed" meant "lapsed in paying dues." If it doesn't, then perhaps we need some other term like "in arrears."
Perhaps what we need is a way to specify a length of time after which we will no longer consider the person as "in arrears," but rather, simply not a member at all -- what you are now calling "lapsed." The member level adjustment allows us to do that, but only if the member record isn't archived. And again, we cannot afford to pay for members who are not paying us. We have to archive members who aren't paying, even if they are just "in arrears" rather than fully "lapsed." Is this what you mean by #1? I am not sure what an extra "renewal action step" means.
If we can distinguish "in arrears" from "lapsed," then as for #2 the simplest thing would be to keep the current renewal day and catch them up to the minimum year that makes them a current member. I guess if some WAers don't want this, you should tell them that the appropriate category is "lapsed" rather than "active," just the way you are now telling me that I am using the categories inappropriately. It is hard for me to imagine why anyone would want their members to pay back dues without actually paying enough dues to be current.
Sorry, I know you asked for comments from other users, but I had more input to give.
I should mention that this feature isn't really working in a very good way in any case. Let me give an example to illustrate what I mean. Suppose a person should have renewed by 1 Feb 2010, and suppose they are kept as an active member. And suppose that renewal for the Society is on a one-year, date of sign-up basis. Now it is 24 May 2011 and they've come to pay their dues and back dues. The default that Wild Apricot gives them is to renew from 1 Feb 2010 to 1 Feb 2011, which does not make them current with their dues. In order to be current with their dues, they have to renew a second time. Most members don't notice this, and so it requires an additional explanation and an additional step on their part, with possible frustration on both sides. It seems to me that WA should, at a minimum, flag for the member that renewing for one year does not make them current with their dues. It would be even better if the default was to renew them until 1 Feb 2012 (in the above example).
Thanks for your suggestions, but they won't work for our situation. The basic problem is that we have about 500 members, give or take. That is right around your price point where it makes the difference for an extra $50/month if we go over the 500, and that's a lot of money for us. We have conferences once every two years and our members can be lax about renewing. So, we need to archive people when they haven't paid in order to save money.
I love the new ability to customize the donation form. However, I am wondering if it would be possible to integrate donation items with the membership and event registration forms -- so that when renewing membership or registering for an event, one can make the choice to make a donation as well. Here is the reason this would be desirable: We find that when people are already paying money, they are thinking about us and willing to throw in a small donation, too, in contrast to the standalone link to donations which is almost never used. We used the "radio buttons with extra cost" to solicit donations. However, there was no option for people to enter a custom amount for their donation. So, I guess what I am asking for is either 1) add the functionality to include a custom amount on the membership and registration forms or 2) add the functionality to include the donation form information on the membership and registration forms. The first is probably simpler to implement -- and would probably be fine for our purposes. The second is a bit "slicker" and might make tracking donations a bit easier.
You're coddling us. A lot of places would just say "you're responsible for your own backups and your own mistakes."
It's nice that you're coddling us, though. :-)
I've seen software that popped up a message that says, "Warning: this change is not undoable." You could supplement that with "We strongly recommend that you download a backup copy of your database. Click here to download" (or something like that).
Of course, undo would be great. But I'd rather have the bulk changes first if undo is the holdup. I would never have even expected an undo.
It might be better to have an email actually sent out to the person, if you really want to make sure that it is a working email address.
Whenever I'm asked to enter my email address twice, I just use copy and paste. :-)
Will be available in the next system update.
Hmm... It's a good idea, but I can also see where the email role and the forum/blog role might need to be separated.
What kind input are you looking for? Specific ways that we might accidentally screw up our data?
I do worry about data loss and try to remember to do backups, but I'm forgetful. I'd find the following helpful: Every X days/months (user setting), send an email to the administrator with a reminder to do a backup. Ideally, with a link to where you need to go to in Wild Apricot to initiate the backup or backups. And yes, whatever is exported ought to be importable, assuming that the data hasn't been savaged in some way.
(What would really be good is a completely automated backup. But I can't see how that would be possible).
241 votesEvgeny Zaritovskiy responded
Please review results of our analysis and design:
Post your comments/ideas right here. Until we see major disapproval, this is what we will develop in one of future releases.
A listserv function would be very useful for our organization, especially if it had a "moderator" function. We currently outsource this; having Wild Apricot do it would help consolidate things.
We would need to have ours printed with name and organization, with perhaps the option to include some sort of little icon down at the bottom (say, a star) for those who paid for the optional banquet.
Our badges tend to be the sort that are stuck in the little plastic sheaths and strung over the neck. Any standard size for which sheaths are available is fine.
This would save us a lot of effort. We're all volunteer-driven, and not everyone knows how to do the mail merge.