Mailing Preference Attributes

Gemma Windle

The charity I work for used to record mailing preferences under Solicit Codes, but following professional advice and addittional training moved these over to attributes earlier this year, before I took up my post. These have begun to get quite complex and include:



Do not mail (recorded with description = yes)

Do not contact (recorded with description = yes)

Do not email (recorded with description = yes)

Do not thank (recorded with description = yes)

No financial asks (recorded with description = yes)

No Upgrade Asks (recorded with description = yes)

Annual Review only (recorded with description = yes)

Email Opt-in (recorded with description = yes)

Phone Opt-in (recorded with description = yes)

Mail Frequency (description = once a year, 3 times a year or reduced mailing) (not often used)



As you can imagine, this makes forming queries for email lists etc rather difficult. We have just moved from NetCommunity to Online Express, and I have been tasked with deciding how to record unsubscribes. Allthough OLX prevents unsubscribers being mailed, we wish to make a record of this data in RE. How can I simplify our mailing preferences and record unsubscribes without compromising on the levels of detail we have recorded?



Any thoughts, experience or advice would be greatly appreciated, thank you!



 

Jen Claudy

I also use Attributes rather than Solicit Codes.  However, I have 3 attributes (Newsletters, Invitations & Solicitations, and our In-Kind gift drives).  The Description field for all 3 is the same table, and includes Remove from List (per Constituent), Do Not Mail (per our organization), Electronic Only, Print Only, Employee, Mail All, and Special Instructions.  Particularly for the Special Instructions, the comment field either indicates what those are, or references a Note.  We try to put in the Comment for all of them where the instruction came from, and always update the Attribute Date so we know when the tag was added to the record.  Pretty easy to manage, in my experience.  The system you have seems like it could be reasonably easily converted to a system of fewer Attributes, although unlike ours where the Attribute can only be used once per record, you may need to have multiple instances.  It depends on the volume of useage, and something like a Special Instructions option with accompanying instructions in the Comment could fit the bill.



For OLX (we've been using OLX for just about a year now), we have a slightly different system.  There is an eCommunication Attribute that is used to include people on our main email list when there isn't another, more efficient, method of getting them on the list.  But whenever possible, we use other means of querying records to compile OLX lists, for example, board members and staff come from the Volunteer Tab, when someone joins or leaves, that information is changed, and the OLX dynamic query updates the list automatically because it's pulling from a query using Volunteer Tab data.  (Note: presently, we really only have one list in OLX that is used regularly, anything else is a one-time message with a custom list just for that message that often is compiled with a temporary Attribute which is deleted once the message is sent.)



As to unsubscribes, we needed a way to tag them in RE during the process of moving everyone from Constant Contact to RE for OLX.  So I created additional Phone Types.  We have eHome and eWork, but now also XeHome and XeWork.  When we send an OLX message, I push the data from OLX to RE about 2 weeks later, and then run a query for all those with the response Opt-Out.  I review and manually change any that have more than one email address, and then use a Global Change to flip the remainder from eHome to XeHome and eWork to XeWork.  OLX includes the specific email address in the Appeal Tag, so it's very easy to determine which address, if there are multiple, is the one that was unsubscribed.  Using a different phone type means that the data is still in RE, so no one accidentally puts it back in there without realizing, and our staff can still use that email address for specific/direct messages, so long as it's not also marked Do Not Call (and in 7.95 we'll be able to add a Comment right there in the Phones grid to clarify).  We also use the X Phone Types to indicate hard bounces, although OLX as yet doesn't distinguish between hard and soft bounces...you can figure this out by querying for Appeal Response of Bounced and then whether they got the next Appeal at all, which if no, seems to indicate a hard bounce and if yes, would seem to indicate a soft bounce where OLX tried again.  I've done a little with this, but not on a regular basis.



Occasionally, I'm asked to do a mailing where we email those on the list for whom we have email addresses and send postal mail to the rest.  In these cases, it is really important to know what email addresses have been unsubscribed, or else they may not get the information at all.  That's primarily what started our system...and trying to be sure that emails unsubscribed in Constant Contact remained unsubscribed when we moved to OLX.



Hope this helps...and hope I'm making sense, because it's been a rough morning and I'm a bit under the weather...

Christine Cooke 2

If you must keep them in Attributes instead of Solicit Codes then I suggest ONE Attribute that is "Contact Preferences" or "Mail" and then the Description should be a table defined drop down of all of the choices that you now have a separate Attributes.  Right now, not only is that clunky for query building, but your Attributes tab is going to get crazy crowded.  So many things get dumped into Attributes instead of giving a little more thought to the functionality of other areas of RE that are more appropriate...

Alan French

Christine Cooke:

If you must keep them in Attributes instead of Solicit Codes then I suggest ONE Attribute that is "Contact Preferences" or "Mail" and then the Description should be a table defined drop down of all of the choices that you now have a separate Attributes.

We used to do it this way but have recently changed to one attribute per mailing, because we were running into issues where people would have both "send enewsletter" and "do not send enewsletter" attributes as they could have an unlimited number of attributes from the Mailing category. If one or both attribute dates were blank, we had no way of knowing which should supersede the other; having a separate attribute per mailing means we can just check the configuration option for "allow only 1 per record" and this problem is eliminated.



We also use solicit codes for more generic opt-outs, e.g. do not call, no fundraising, no direct mail etc.

Gemma Windle

Jennifer Claudy:

I also use Attributes rather than Solicit Codes.  However, I have 3 attributes (Newsletters, Invitations & Solicitations, and our In-Kind gift drives).  The Description field for all 3 is the same table, and includes Remove from List (per Constituent), Do Not Mail (per our organization), Electronic Only, Print Only, Employee, Mail All, and Special Instructions.  Particularly for the Special Instructions, the comment field either indicates what those are, or references a Note.  We try to put in the Comment for all of them where the instruction came from, and always update the Attribute Date so we know when the tag was added to the record.  Pretty easy to manage, in my experience.  The system you have seems like it could be reasonably easily converted to a system of fewer Attributes, although unlike ours where the Attribute can only be used once per record, you may need to have multiple instances.  It depends on the volume of useage, and something like a Special Instructions option with accompanying instructions in the Comment could fit the bill.



For OLX (we've been using OLX for just about a year now), we have a slightly different system.  There is an eCommunication Attribute that is used to include people on our main email list when there isn't another, more efficient, method of getting them on the list.  But whenever possible, we use other means of querying records to compile OLX lists, for example, board members and staff come from the Volunteer Tab, when someone joins or leaves, that information is changed, and the OLX dynamic query updates the list automatically because it's pulling from a query using Volunteer Tab data.  (Note: presently, we really only have one list in OLX that is used regularly, anything else is a one-time message with a custom list just for that message that often is compiled with a temporary Attribute which is deleted once the message is sent.)



As to unsubscribes, we needed a way to tag them in RE during the process of moving everyone from Constant Contact to RE for OLX.  So I created additional Phone Types.  We have eHome and eWork, but now also XeHome and XeWork.  When we send an OLX message, I push the data from OLX to RE about 2 weeks later, and then run a query for all those with the response Opt-Out.  I review and manually change any that have more than one email address, and then use a Global Change to flip the remainder from eHome to XeHome and eWork to XeWork.  OLX includes the specific email address in the Appeal Tag, so it's very easy to determine which address, if there are multiple, is the one that was unsubscribed.  Using a different phone type means that the data is still in RE, so no one accidentally puts it back in there without realizing, and our staff can still use that email address for specific/direct messages, so long as it's not also marked Do Not Call (and in 7.95 we'll be able to add a Comment right there in the Phones grid to clarify).  We also use the X Phone Types to indicate hard bounces, although OLX as yet doesn't distinguish between hard and soft bounces...you can figure this out by querying for Appeal Response of Bounced and then whether they got the next Appeal at all, which if no, seems to indicate a hard bounce and if yes, would seem to indicate a soft bounce where OLX tried again.  I've done a little with this, but not on a regular basis.



Occasionally, I'm asked to do a mailing where we email those on the list for whom we have email addresses and send postal mail to the rest.  In these cases, it is really important to know what email addresses have been unsubscribed, or else they may not get the information at all.  That's primarily what started our system...and trying to be sure that emails unsubscribed in Constant Contact remained unsubscribed when we moved to OLX.



Hope this helps...and hope I'm making sense, because it's been a rough morning and I'm a bit under the weather...

Thanks Jennifer!



I'm definately keen on narrowing down the number of attributes. I'm not sure whether special instructions would be very useful to us, as it would be difficult to pull that data through for mailing lists- but it may be worth considering for the Do not Contact (per organisation) attributes.



Thanks for your help and I hope you feel better soon!

Gemma Windle

Alan French:

Christine Cooke:

If you must keep them in Attributes instead of Solicit Codes then I suggest ONE Attribute that is "Contact Preferences" or "Mail" and then the Description should be a table defined drop down of all of the choices that you now have a separate Attributes.

We used to do it this way but have recently changed to one attribute per mailing, because we were running into issues where people would have both "send enewsletter" and "do not send enewsletter" attributes as they could have an unlimited number of attributes from the Mailing category. If one or both attribute dates were blank, we had no way of knowing which should supersede the other; having a separate attribute per mailing means we can just check the configuration option for "allow only 1 per record" and this problem is eliminated.



We also use solicit codes for more generic opt-outs, e.g. do not call, no fundraising, no direct mail etc.

 

I don't think we could manage to limit it down to one attribute per mailing, but I may consider making the email opt-in table 'subscribed' or 'unsubscribed' and appear once only to avoid this, as we have this problem to. If only there was a way of making date and description mandatory! As I said, we have been advised against solicit codes, so I'd be reticent to change back, especially as using both in queries caused all sorts of problems for us.



Thanks Alan and Christine!