Mail Preference and Solicit Code Overrides

Tia Parker · April 2021

I am in the midst of a solicit code and communication preferences clean up. My organization currently tracks both solicit codes (opt-out preferences) and mail codes (opt-in preferences) through attributes. When I started, my organization found that the Solicit Code field did not allow for enough information to be captured, such as date of add and comments on why the solicit code was being added and so the move was made to attributes. Now, the solicit codes and mail codes lists seem to have grown somewhat unchecked. We have codes that only pertain to each event and mail/email list that are quite specific (opt-in/out of each of our appeal mailings and emails, opt-in/out of each of our corporate partners/donors/annual report newsletter mailings and emails, opt-in/out of each of our galas and stewardship event invites by mail and email etc.). What are some top level codes that your organizations have used for opt-in or opt-out preferences? I know that a lot of it depends on the organization but I'm trying to get a sense of what a more manageable list of codes would be.

Our list of codes has also led to confusion on which codes take priority. For example, if someone opts-out of all paper mail, but then requests just the Holiday mailing every year or still likes to receive the donor newsletter by mail, how have you coded something like this where one code needs to override another? Or I suppose alternatively, how have you set up queries for mailing lists to account for donors that don't want paper mail, except for X mailing each year?

Heather MacKenzie · April 2021

Good luck with your project, first of all!

I have always found solicit codes to be enough - with still general titles, like "Do not mail - events", and in a former database, we had an "Opt in for year end" code. Our mailing lists are all based on queries, so I can use the "One of" field to select exactly who I need to either include or exclude. Check out query lists if you haven't already, and also the consent module. I am still learning about the consent module and what it can do, but here's how I use query lists to help out. Exclude the heck out of your list, dump the final product into a query list, and then you can add back in the group of opt-in records.

Also, in my current database, we do pair it with an attribute that is called "Communication Tag." This attribute lets us specify that the donor emailed to request to be removed, or that the email address on file bounced with the April 27th email blast or whatever is applicable. But the preferences are still in solicit codes.

Tom Klimchak · April 2021

Ooo.. good question! We've had RE for 11 years and we transferred over from a legacy system so we kind of took our existing plan and modified it for RE. Our most common solicit codes are:

Do Not Contact
No Phone
No Magazine
No Mail
No Texts
No Reminders
No Solicitation

Then we have a few special cases ones which we don't use all that often. We've debated making "inclusion" solicit codes for certain mailing types and purposes "Email - Arts, Email - Athletics, Email - Alumni News" etc but I've fought it because I'm terrified of it spiraling out of control.

As for putting people IN to certain lists we're still "old school" and use an Attribute called "Mailing List" which has a table of about 15 values.

When we put together big mailing lists and need to INCLUDE people on the "Arts Mailing List" even if they have "No Mail" we sometimes just take on an "OR" statement at the end of our query to pull them all in (after No Mail people have been removed from the main criteria). Our mailing list criteria are sometimes 20 or 30 lines long (bonkers) so in those cases I tend to just pull the list separately and either merge queries or export it out and tack it on the end in Excel.

There have been lots of good "Solicit Codes" discussions on the forums over the years. Feel free to search for the term and you'll come up with all sorts of interesting answers :-)

Jeannie Goings · April 2021

Not sure if this is true, but when we implemented BBNC, our implementation guide told us that BBNC is going to look at the restrictions in the consent module. Because of this, I configured the consent module to add/remove solicit codes based on constituent response. We have the "absolutes" Do Not Phone, Do Not Solicit ... that apply to all categories. Our our categories are by team: annual fund, engagement, planned giving... If planned giving sends an email and a constituent unsubscribes, the solicit code that is added to the record is plannedgiving@. The criteria for a future email lists for planned giving excludes records with solicit code plannedgiving@.

After our conversion and before our BBNC implementation, our mailing preferences were imported as attributes. We are in the process of converting the attributes to consent. Our legacy db separated solicitation codes and mailing preferences; in RE/NXT it feels like solicitation/consent is one giant fruit salad. The other I will share is start and end dates for solicit codes can be entered from NXT, but not db view, but there is no way to query the dates AND there is no export function for consent. Like I said: giant fruit salad.

If you have experience with BBNC and can confirm that my opening sentence is false, I would love to hear from you.

Karen Diener 2 · April 2021

I very much follow Tom Klimchak‍'s model. Every organization I've worked with that has "inclusion" as well as "exclusion" criteria in their solicit codes has a mess on their hands and cannot pull accurate mailing lists. And whenever I've audited that specifically, there are codes on constituent records that cancel each other out - they have "all mail" as well as "no solicitation". No idea how to interpret it.

Before Consent was an option, I usually advised for exclusionary solicit codes, and mailing list attributes to put people on lists even if they didn't meet the criteria for the mailing. When solicit codes were added, staff was instructed to add a Constituent note (type = "solicit code" so we could easily find and query it) explaining what code(s) they added, when, and why. They didn't always do it, but it was really helpful when they did!

Karen

Christine Cooke 2 · May 2021

Similar to Heather MacKenzie‍ the focus is on gathering folks by utilizing queries (one or more depending on how complex the list is) and Solicit Codes to exclude. There are handful, literally, of opt-in. Everyone you're looking for should be able to be captured through query criteria. I always pull by having one or a series of queries depending on how many different and far flung areas the list is being pulled from. and then the last two steps are doing a subtraction query merge of solicit code(s) of folks that are not supposed to get it. And finally, if there are some who are supposed to no matter the solicit code, they are added back in with the or operator query merge. There are plenty of other details that determine whether the records you want are event peeps or donated two years ago etc.

Solcit Codes are kept straightforward, being all Do Nots. Do Not Solicit, Do Not Mail, Do Not Invite, Do Not Call, Do Not Email and the elusive only used on maybe 3 records tops in unusual circumstances Do Not Contact for Any Reason Whatsoever.

Requests for the Do Nots are noted in the constituent notes.

If you write all of your criteria in one query - the this but not that and this but not that -- you will end up with nots in your final list. And as fate would have it, usually the nots that you really, really don't want. It's better in my experience to have the nots/exclusions in a separate query that pulls those records out with a query merge.

Gemma Windle 2 · May 2021

For those of us in the EU / UK (and possibly Canada and Australia too?), Heather MacKenzie‍ 's solution is not GDPR compliant as we have to record the date and source of any consent. This is why Blackbaud built the consent module.

Gemma Windle 2 · May 2021

I've just moved to a new role, and I'm also doing this clean up! I'm in the UK, so we have to abide by GDPR. We're also a big org with a lot going on, and lots of requirements from different teams. Sometimes we need to exclude people from communications about particular things (categories) and sometimes its just a whole channel.

My current plan is to have 4 levels of solicit code, with 1 being the most important, 4 being the least. Levels 1-2 cover Data Protection, level 3 allows us to exclude from specific categories of comms, and level 4 allows us to offer really granular preferences to those who want it:

Misc/Data Protection

1. Do not share data with third parties

1. 'Removed' from database

1. No further contact

Channel

2. No Phone

2. No Mail

2. No Email

Communication Content (Category in consent)

3. No Financial Asks

3. No Legacy Asks

3. No Volunteering Asks

3. No Event Asks

Granular Preferences

4. No Financial Asks by Phone

4. No Legacy Asks by Phone

4. No Volunteering Asks by Phone

4. No Event Asks by Phone

4. No Financial Asks by Mail

4. No Legacy Asks by Mail

4. No Volunteering Asks by Mail

4. No Event Asks by Mail

4. No Financial Asks by Email

4. No Legacy Asks by Email

4. No Volunteering Asks by Email

4. No Event Asks by Email

So, to send out a mailing with a financial ask in it, we would exclude:

1. 'Removed' from database

1. No further contact

2. No Mail

3. No Financial Asks

4. No Financial Asks by Mail

If anyone can see any problems with this please do call me out on it! I've not configured this before, and this is the most sensible thing I can come up with that meets everyones' needs : )

Obviously, mapping consents to these will be a big job, but it will be worth it.

Heather MacKenzie · May 2021

Gemma Windle:

For those of us in the EU / UK (and possibly Canada and Australia too?), Heather MacKenzie‍ 's solution is not GDPR compliant as we have to record the date and source of any consent. This is why Blackbaud built the consent module.

Thanks for pointing this out, Gemma Windle‍! I'm super curious about GDPR rules and regs.

Daniel R. Snyder · June 2021

Gemma Windle‍ I think you are right on and regardless of whether you need to comply with GDPR or not I would say take the time to set up your consent module. Yes, it takes time and thought, but will save you a lot of time and thought going forward.

Jayne OLeary · September 2021

Our organization is also doing cleanup but realize some of these solicit codes are hard wired based on the communications consent part from NetCommunity. So I am looking to find definitions to these individual consent codes or at the least find out how they were added to RE. Anyone have any idea where to at least find definitions?

Mail Preference and Solicit Code Overrides

Comments

Categories