When I create mailing lists, I find that I am having to create very complex suppression queries in order to account for all the possible constituents that I do not want to mail. Some of the mailing information is in solicit codes, some of the suppression is based on constituent codes and then I need to suppress all those donors who have received certain other mailings -- information which I code as an assigned constituent appeal. It seems I have information relating to mailings in too many places, but what do some of you do? Does all of this information end up as an attribute?

I really like using the assigned constituent appeals for mailings because it makes reporting on the success of a mailing so easy (as long as we code gifts properly) so I would like to continue doing that.

Thanks for your thoughts.

 Laurie Nielsen

I think it depends on what you are mailing and why. Many of us have different types of mailings that we do and therefore would use different criteria (or combinations of criteria) for each mailing. Newsletter mailing Queries would be different from Queries for solicitation mailings and Queries for event invitations would be different still

In my opinion:

If your mailing is a solicitation or likely to produce results = $$$ the assigned constituent appeal and corresponding gift appeal (Code the reply device for your data entry staff with that assigned constituent appeal)

If it's an invitation to a non-revenue generating event I would suggest using the event module or a constituent attribute (example Board Meeting or recognition event invitation where you are tracking rsvps)

If it's an invitation that genreates revenue such as a gala you could do Constuituent Assigned Appeal or Constituent Attribute

If it's a newsletter that generates revenue (even if it's a 'soft' ask) Constituent Appeal works - but Constituent Attributes could be used.

Solicit Codes I use on an exclusionary basis: Do Not Solict - this means they don't receive solicitations but may receive invitations or newsletters or annual reports Do Not Invite - this means you can solicit but don't send invitations to events Do Not Mail - this means no mail at all period No Spring Solicit - for us this means not to mail them at all in any of the spring mailings, but please still mail them in the other 3 seasons. These are just examples of how I use them, if you do a search on the forums there is some pretty lively discussion on how everyone uses them differently.

There are some folks that may use an attribute to indicate inclusion in specific organizational mailings, but I would use those only to cover those folks who wouldn't normally be included in your criteria for the mailing as opposed to coding everyone you want to get a certain mailing (this is because your database is growing and changing all of the time). If you are managing mailing lists for other departments that also may be a reason to use an attribute.