How to temporarily remove constituents from solicitations & add back in at later date

Jane Owsley

Hello.  What is the best way to flag/code records to temporaily remove constituents from solicitations for a period of time, but then would prompt to add them back in at a certain time.  For example, a job loss may warrant a donor to request to not be solicited for the next year, or for those making recurring gifts with an end date, we would want to make sure they were included when their RG had stopped.  How do we indicate a record is "No Solicitation" now, but in two years, we want to make sure the record is added back in to solicitations.

Thanks so much for your insight.  The Forum community is such a great resource!



Jane Owsley

Jennifer Donlevie

Maybe you could use a solicit code and/or an attribute to mark for do not solicit, then add an action for two years in the future to add them back in (with an action reminder) then when the reminder comes up, you could remove the old solicit codes.  Good question!

JoAnn Strommen

Jane,

Are your prospective donors identified by an attribute/solicit code or do you include everyone in your database?  My first thought would be either an attribute or solicit code stating something like 'no solicitation until 20XX."  Then it would be a manual process to remove/change that code.



Our prospects for specific campaigns are identified as such or as not to be contact using an attribute.  It works for us.

Carolyn Moatz

We have a few of these from time to time. We mark them as do not solicit (we use an attribute, but however you would normally mark someone to make sure they don't receive solicitations is what you should do), and I put an action on the record for the date we either want to add them back in, or re-evaluate them (usually the beginning of the next fiscal year) with a note explaining the situation (he is ill, she is upset about something, etc.) and telling me to remove the do not solicit attribute. I set up a reminder in the action for me.

Jen Claudy

Our solicit codes live on Attributes, and one of the Description options is "Special Instructions" then those instructions are in the Comment, with more detail on a Note with Type "Solicitation/Mailings".  We have some that those instructions are "DNS until FY17" or "Solicit Annually, Only in Fall" and then these are reviewed for every mailing.  We will also add the Appeal tag to the record, with a package of "Do Not Mail" so that if someone ever asks why so-and-so didn't get this mailing, we can easily see that they met the criteria, but were removed from the list because of a solicit code (or whatever the case may be).  The solicit code Attribute gets updated whenever necessary (including the Date) but the Note stays as-is, so that explanation stays in the database and is accessible in the future.

Matt Page

I like Carolyn and Jennifer's answers, but I have inherited a different process.



As we're a hospice, we routinely exclude next of kin etc. for six months after a death. To do this we give them a month code (which are excluded from mailings), and then prior to each main mailing we review these and remove those codes from anyone who is past their six month date.



Matt

Jane Owsley

Thank you all, these are great suggestions!  We use Contact Rule Attributes to capture a variety of situations and I like the idea of the "Special Instructions" instead of using the similar "No Contact" or "No Solicitation" attribute since this would highlight the group that are in the temporary no-solicitation status.  We were thinking the Action reminder routine would make the most sense, thank you for helping us confirm this is solid direction to explore.  



Jane