Dealing With Lapsed Members

Removing lapsed members from association list servers requires frequent checks of all members of each list against the member database.

Integrating Lyris visually with ATLA's web site and standard security was adequate to get started but obviously with the passage of time, some members would allow their memberships to lapse. If the web site and its services including the list servers are part of the member benefits package, lapsed members cannot be allowed to remain in the lists for long. Here the availability of an API is critical as this is a much more complex issue than replacing one standard set of Perl defined page headers and footers with another. Manual procedures for maintaining the lists are out of the question, if the lists are large enough to be considered successful.

To be integrated with an association web site and or member database, a list server has to provide a tool set that lets you retrieve email addresses from the lists and match those email addresses to the member records. Based on your rules defining current members, you then need to remove all who are lapsed or no longer eligible, from the list. Since these are people who are or have been paying for access to association services, it is very important to notify persons being removed from the list of this and why. Since list servers are by definition email based, email notifications are the obvious mechanism. This has the advantage of being an automated retention tool based on a service the member chose to take advantage of.

Besides its member oriented lists, ATLA had some public lists that had little or nothing to do with its membership activities as well as committee lists that were managed quite differently and test lists. Other associations are likely to have similar situations. We created a definition or parameter file in which various processing options can be turned on or off for each list defined in the file individually. This was a private configuration file which all our list related custom programs used to determine which lists to process and what to do with them.

For membership eligibility enforcement, a Perl script was developed to run nightly. It read the private configuration file and for each list that had an indicator that the list was to be limited to eligible ATLA members, made a Lyris API call to get the list of all current members (by email address and with their name as well). These lists were processed in an inner loop and the email address was used to retrieve the member record(s) containing the email address.

If an email address in a list could not be located in a member record or the member record in which it was located was lapsed, the email address was removed from the list and sent an appropriate email notification. Unfortunately, it was really was not quite this simple because numerous members were found to share the same email address as described on the following pages.

Top of Page - Site Map

Copyright © 2000 - 2006 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth on http://GeodSoft.com/terms.htm. These terms are subject to change. Distribution is subject to the then current terms, or at the choice of the distributor, those defined in a verifiably dated printout or electronic copy of http://GeodSoft.com/terms.htm at the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior permission is obtained from George Shaffer. Distribution in accordance with these terms, for private, unrestricted and uncompensated public access, non profit, or internal company use is allowed.