No mailings, newish employee, many changes...

Options

We have a new-ish gal who has joined our partner relations team this past year. (The previous gal was familiar with RE and things worked great.)

She has taken various classes for mailings and her job. I am unsure what kind of query she needs to run but the issue is pulling constituents who do not wish to receive mail.

For the past two years with RE (and with the previous program,) we marked people Do Not Solicit (which is our solicit code) to filter them out. The previous mail gal also created an attribute - Mail_Status_Code (no mail) for whatever reason.

My question, as I've had to involve management as these constituents were being marked no valid address (which doesn't show their address for printing receipts) and now inactive in an attempt not to pull people who do not want mailings. Is there a better way or was Do Not Solicit the way to go?

Thank you in advance for your expertise!

Tagged:

Comments

  • Marie Stark
    Marie Stark ✭✭✭✭✭
    Ancient Membership Facilitator 3 Name Dropper Photogenic

    @Dana Burton We use solicit codes. These can be excluded in you query (Solicit code does not equal Do Not solicit).

  • Dariel Dixon 2
    Dariel Dixon 2 ✭✭✭✭✭
    Seventh Anniversary Facilitator 4 Name Dropper Photogenic

    I have to agree with @JoAnn Strommen. Especially the part I emphasized here.

    @Dana Burton I would definitely discourage marking people as ‘inactive’ or ‘no valid address’ just on the fact they don't want to be solicited. That is the purpose of solicit codes and/or attributes.

    Your org should define what/when someone is marked as inactive. And might not hurt for when to mark ‘has not valid address.’

    For mailings, using query and/or exports etc. it is easy to filter out records with a 'Never solicit" solicit code or an attribute to that effect (I recommend one or the other. I inherited both and do like that attribute has date and comments for why it was added. Also be as specific as appropriate - I have many records with solicit code of “No Mail”. No one is sure what/why. So we are now using a code of No Fundraising Mail as many still want other mail.)

    I won't rehash JoAnn's statements, but just add-on that in the grand scheme of things, it really doesn't matter, as long as it's documented and consistently followed. Attributes and solicit codes can easily be queried on and excluded if necessary, and depending on your DB structure, I don't think it matters too much. It does need to be acknowledged that inactive should probably be used for something specific, or totally ignored altogether.

  • @Dana Burton - I also agree with @JoAnn Strommen.

    As long as your organization is consistent with documentation on how to mark Do Not Solicit whether it is a Solicit Code or Attribute, you are fine. I have use Solicit Codes like Do Not Mail because they want to receive no mail from our department or Do Not Solicit to indicate no solicitation but we mail newsletters or other stewardship materials. I also create a note in the record as to why the solicit code was assigned.

  • Thank you @JoAnn Strommen and @Dariel Dixon. The Do Not Solicit is part of our solicit code. In my mind, this and attributes is how it should be done but thought I'd also check with those having more experience. Thank you so much for your time!

  • @Dana Burton, echoing what others have said: “Do Not Solicit” is different from “Do not mail” or “Inactive”. DNS means they don't want solicitations, but they may enjoy our newsletters, Christmas cards, or event invites. “Do not mail” means they don't want ANY snail mail, but they may be very active on our email list. “Inactive” means basically that they never want to hear from us again in any form. We use Solicit codes for list filtering, plus an Attribute to denote context.

Categories