Marking Constituent Records for Specific Mailing Lists

Nate Laning 2

I'm doing research on how to best mark a set of constituent records to be on a certain mailing list (like a newsletter list). Historically, our office has used a special Solicit Code for this purpose. However, I'm wondering if Attributes would be a better location for such labels.



Can anyone please shed some light on how their office handles such lists? Thanks!

JoAnn Strommen

Our newsletter mailing list are created based on giving history and/or constituency.  We do use solicit codes for some exclusions from mailing lists. 



My observations from reading posts is that many use solicit codes for exclusions or limits on what is sent to a constituent. 



Attributes could be used - I'm very stingy on adding attributes as I don't want list of attributes to become overwhelming.  If you do use attributes, I would definitely recommend a table for your description field so that you have consistent data entry and can use the field to create your mailing lists.



Just one users thoughts/experience.

Alan French

We use attributes for our mailing lists. The category is the name of the mailing, and as JoAnn has recommended we do use a table - the descriptions are limited to:

• "yes" for people who are eligible to receive the mailing
• "yes (opted in)" for someone who wouldn't ordinarily meet the criteria to be included but who has specifically asked to receive it
• "no" for people not eligible to receive the mailing, and
• "no (opted out)" for people who are eligible but have unsubscribed. This prevents us from accidentally adding a "yes" back onto the record at a later date without realising they've previously requested not to receive it.

One advantage to using attributes is that they can be limited to 1 per constituent. We've only added this restriction to mailing attributes lately, but it does eliminate the problem of constituent records having multiple conflicting options for the same mailing with no way of telling which should supersede the other.

Peggy Weisensel Chavey

We have a table-based "Opt-in Mailing List" attribute. The table contains all the possible mailing lists. The attribute comment field is used for any qualifiers or notes regarding the particular mailing list membership. Our solicit codes are only of the "do not" variety.

Shannon Doiron 2

We used solicit codes...Do Not Mail, Do Not Solicit, Terminated (moved out of area etc), Newsletter Only, Email only, Holiday mailings only, etc.

It works for us although I know others probably use Attributes.

Michelle Kolak

We have a table called Distribution Lists.  For some of the lists, only those who have the attribute will get the mailing.  For others, we add the attribute to the criteria so that they get it even if they do not fall in the general list.

Jennifer Reager

Online Express has helped us in getting our email and eNews folks more organized, but for direct mail, we still rely on queries - sometimes rather complex queries. 



Now, they may have a certain Attribute or Constituent Code that we can use to include or exclude them from the queries, but most commonly we query on criteria like giving history, Date Added, volunteer activity, etc.

Nate Laning 2

Thanks to everyone who has responded! This is very valuable information and will help us make a good plan for our mailing lists. I appreciate the help!

Christine Cooke 2

Any Org. I have been at, things like a newsletter, were based on specific criteria, like giving history and constituent code.  For other things, like events, or special circumstances, we had an Attribute that tagged folks as sort of a Sub-Constit Code (2ndary level), such as UCSF affiliates, or Admission Dept contacts, or President's affiliates.  Because there were circumstances or times of year that required that one or more of those finite groups were included in the mail list, but the rest of the time they were excluded.



So I would consider carefully what the tag(s) will be utlilized for, in what circumstance, and are there other ways that you pull the same criteria.  Because if it is something like "newsletter"  that would have to be constantly maintained, as opposed to once a year or once in a lifetime.