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 - 2014 by George Shaffer. This material may be
distributed only subject to the terms and conditions set forth in
http://GeodSoft.com/terms.htm
(or http://GeodSoft.com/cgi-bin/terms.pl).
These terms are subject to change. Distribution is subject to
the current terms, or at the choice of the distributor, those
in an earlier, digitally signed electronic copy of
http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the
time of the distribution. Distribution of substantively modified
versions of GeodSoft content is prohibited without the explicit written
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 written permission is obtained from George Shaffer.
Distribution in accordance with these terms, for unrestricted and
uncompensated public access, non profit, or internal company use is
allowed.
|