How Does Your Org Handle Bounces and Unsubscribes?

To be clear, we currently handle bounces and unsubscribes poorly.  We are approaching the end of a process that will allow us to handle them much better.

First, there are two kinds of bounces, soft and hard.  Roughly, a soft bounce equates to a delivery failure, while a hard bounce is something like a response from the address' server saying that the address does not exist.  According to my notes, a long time ago industry guidance was to translate certain number of soft bounces into a hard bounce, but this guidance changed, and now we simply ignore soft bounces.

We used to de-primary, inactivate, and change the EAddress Type on hardbounces.  Our new plan is to de-primary and inactivate (this does not prevent logging in with the login tied to this EAddess in TNEW, incidentally) the EAddess, but instead of changing the type we are going to add a Contact Point Purpose of "Hardbounce".  We already have a Contact Point Purpose Category of "Contact Point History" that we used for flagging changes in mailing address.  This way if the customer contacts us about not receiving email, the representative can see the address and why is no longer being used.

These days (this was not always the case) when you get responses back from Wordfly (and I presume Prospect2) you will get (along with other things) the customer_no AND the email address in question.  For hard bounces we intend to flag every email address that matches the returned email address, regardless of the customer record it is on.

For unsubscribes we are planning to send to customers to a communication preferences screen where they can be explicit about which communications they wish to unsubscribe from.  These will be handled by Contact Permissions.  Instead of "Email, Mail, Phone", we use those as Contact Permission Categories, and have defined Permissions under those that each incapsulate a distinct set of communication types that we send as an organization.

I certainly have some concerns about the fact that customer records may have multiple email addresses.  Also addresses may be inherited from the household account.  However, I think Contact Permissions are the correct tool to use.  It's important to distinguish between the detail available on the customer record and the customer's view of their account.  Absent a custom site, through TNEW customers are only able to see and set a single email address, on their account, and that address will be set as the primary address.  Contact Point Purposes can be set by Wordfly, and (weirdly specifically) by TNEW for Mobile Phones, but effectively they can only be assigned manually by users, and it is really their purpose to handle odd edge cases for VIPs.  "Send this here, and that there, and only mail those." sounds like a great feature, but building an interface for customers to manage it themselves would be a nightmare (can you think of an example of a major retailer that allows this?) and especially a lot of work for the 0.001% of your customers who would actually want to muddle through it.

We reserve Contact Point Purposes to very specific cases where we have a customer who generally interacts with us as a customer, but whom we also have a separate relationship with wherein we might want to address them by a different channel.  An example is our PR contacts.  These people might well be local customers, but also, say, be a critic for a local new organization.  They buy tickets for themselves using personal accounts, but when our PR department wants to contact them, they will want to use their company address (if it isn't the primary), and so a Contact Point Purpose is perfect for this application. 

An issue to consider with managing unsubscribes, whether you use Contact Permissions or are somehow using Contact Point Purposes, is that the unsubscribe is going to naturally be processed for the customer in question, but the email address might be floating around on numerous other customer accounts in Tessitura, either unmerged accounts, family members, etc.  I don't have a good answer for this yet, but I think some action should be taken on those accounts, maybe another "Contact Point History" Purpose assigned to the address on the other accounts.

To be clear, we currently handle bounces and unsubscribes poorly.  We are approaching the end of a process that will allow us to handle them much better.

First, there are two kinds of bounces, soft and hard.  Roughly, a soft bounce equates to a delivery failure, while a hard bounce is something like a response from the address' server saying that the address does not exist.  According to my notes, a long time ago industry guidance was to translate certain number of soft bounces into a hard bounce, but this guidance changed, and now we simply ignore soft bounces.

We used to de-primary, inactivate, and change the EAddress Type on hardbounces.  Our new plan is to de-primary and inactivate (this does not prevent logging in with the login tied to this EAddess in TNEW, incidentally) the EAddess, but instead of changing the type we are going to add a Contact Point Purpose of "Hardbounce".  We already have a Contact Point Purpose Category of "Contact Point History" that we used for flagging changes in mailing address.  This way if the customer contacts us about not receiving email, the representative can see the address and why is no longer being used.

These days (this was not always the case) when you get responses back from Wordfly (and I presume Prospect2) you will get (along with other things) the customer_no AND the email address in question.  For hard bounces we intend to flag every email address that matches the returned email address, regardless of the customer record it is on.

For unsubscribes we are planning to send to customers to a communication preferences screen where they can be explicit about which communications they wish to unsubscribe from.  These will be handled by Contact Permissions.  Instead of "Email, Mail, Phone", we use those as Contact Permission Categories, and have defined Permissions under those that each incapsulate a distinct set of communication types that we send as an organization.

I certainly have some concerns about the fact that customer records may have multiple email addresses.  Also addresses may be inherited from the household account.  However, I think Contact Permissions are the correct tool to use.  It's important to distinguish between the detail available on the customer record and the customer's view of their account.  Absent a custom site, through TNEW customers are only able to see and set a single email address, on their account, and that address will be set as the primary address.  Contact Point Purposes can be set by Wordfly, and (weirdly specifically) by TNEW for Mobile Phones, but effectively they can only be assigned manually by users, and it is really their purpose to handle odd edge cases for VIPs.  "Send this here, and that there, and only mail those." sounds like a great feature, but building an interface for customers to manage it themselves would be a nightmare (can you think of an example of a major retailer that allows this?) and especially a lot of work for the 0.001% of your customers who would actually want to muddle through it.

We reserve Contact Point Purposes to very specific cases where we have a customer who generally interacts with us as a customer, but whom we also have a separate relationship with wherein we might want to address them by a different channel.  An example is our PR contacts.  These people might well be local customers, but also, say, be a critic for a local new organization.  They buy tickets for themselves using personal accounts, but when our PR department wants to contact them, they will want to use their company address (if it isn't the primary), and so a Contact Point Purpose is perfect for this application. 

An issue to consider with managing unsubscribes, whether you use Contact Permissions or are somehow using Contact Point Purposes, is that the unsubscribe is going to naturally be processed for the customer in question, but the email address might be floating around on numerous other customer accounts in Tessitura, either unmerged accounts, family members, etc.  I don't have a good answer for this yet, but I think some action should be taken on those accounts, maybe another "Contact Point History" Purpose assigned to the address on the other accounts.

Thank you for all of this detail, Gawain! Very interesting. I have been wondering about a Contact Point Purpose for "bounce," so it's great to hear this process. Two questions about that: 

1. When you are flagging these, is it a manual process to add that CPP? Or will you somehow have Wordfly write that info back to the record?

2. For purposes of list pulling and extractions, will you be then suppressing those somehow? If a contact has multiple email addresses but one has a CPP of "bounce," how do you handle as a criteria? 

And then regarding the Unsubscribes, how are you sending customers to this screen? Is this through a Wordfly feature of some kind? 

With Wordfly (and I suspect Prospect2?) responses come back into Tessitura, and when they do, they trigger a stored procedure called LP_UPDATE_EMAIL_RESPONSE, which is designed for you to overload with your own code.  That's where we make the hard bounce change.

For lists and extractions, by default only primary, active email addresses will be pulled, and we'll be setting these emails to not primary and inactive.

We initially also used LP_UPDATEW_EMAIL_RESPONSE to record unsubscribe responses, but when we make our updates the "unsubscribe" links in our emails will send them to our Wordfly Preferences page, where they will be presented with a set of our Contact Permissions to update.

I was able to return to this with a bit of attention today, and I think I'm ready to firmly decide to avoid Contact Point Purposes--all of the above gives me great pause, but primarily, it's that I can't put them in front of patrons within TNEW-based Account pages. What's the point (really unfortunate and accidental joke there*) of having a classification preference set up if the people with the preferences can't interact with it?

This will still leave me staring down what I think we actually should do, but at least I'll focus in on Contact Permissions, with attention to how they're Categorized and possibly Typed. In this moment, but perhaps not the next one, I'm pondering if we do multiple "Email" Contact Permissions, to distinguish between the top-most level usages (e.g. public buyers vs patrons in our education program, so opting out of the former communications doesn't end the latter). Or have "email' repeat in some different categories.

David Geoffrey Hall - despite this, I'm going to try again to ask my clarification question in hopes of properly filing this away in my brain. In your initial reply, you mention Contact Point Purposes AND Contact Purposes, and note that the former is on/off and the latter is yes/no/not asked. Can you confirm that they are truly separate things that happen to have basically the same name? Might you point us to the documentation that defines each, and perhaps the spot that has the TNEW aspect explained? (Asking bc I have tried to look this up, but I clearly can't find the right things.) Thank you in advance.

Also, Gawain Lavers, as usual, your response here was invaluable. Thank you.

*Didn't rewrite it after realizing what I'd done specifically for Heath Wilder

Since I wrote about our plans for Contact Permissions and Hardbounces, they have since been implemented.  If you have more questions about our strategy and decisions, let me know!

Accidental - yeah right!

Jamie O'Brien, the way I envision potentially using Purposes is to have a "landing spot" for the bounced and unsubscribed emails, something that is not as top-level as the constituent. I don't think it needs to be a preference that customers can update; it's more micro than that. Or at least, that's what I need!! That may be how Gawain Lavers is using it and if so I'd love to know the specifics. 

That's an interesting thing to think about.

My gut reaction to it is that I want to be strategic (read: uncomplicated) about how many different elements are involved in managing whether an email address is viable or not. Given that we are a smallish institution with this sort of data point literacy being a major part of 1-2 people's jobs and a very minor part of a lot more, I tend to prioritize keeping things simple--or making them look simple--to improve the odds of maintaining what we need correctly. At the very least, I need whatever I propose to have clean lines of definition. 

Maybe Purposes like that fit right in neatly, but my internal mental processing weeps a bit every time *I* try to navigate this terminology so I'm very wary about how it'll seem to less immersed folks. In my ideal world, it's all a pretty diagram that shows A, B, and C as appears on the constituent record; A, B, and C as appears in Extractions (or via lists); A, B, and C as the patron sees it on the website, and A, B, and C as initially created in whatever System Table(s). With A, B, and C looking recognizable as the same things in all those places. (...I know I'm not getting my ideal world....)

Also, I'd really like to figure out how to evaluate what the reality is for my company in terms of multiple addresses. I'm on a bit of a soap box at the moment about making changes based on evidence rather than hypotheticals, so I should apply that here. It might not matter--updating an address rather than a record seems unquestionably practical--but it might help me focus.

When I go down the rabbit hole of looking into this, typically after I've imported a list and received a list of bounces, I find there are two scenarios: 

-Constituent has multiple addresses, in which case one may be viable but is not currently listed as primary (easy to solve, but a manual process)

-Constituent has no other email address, in which case I cannot reach them via email (no real fix, unless they happen to update their profile and/or call the box office) 

In neither case would I want a blanket Contact Permission to apply, as the constituent has not expressed that they don't wish to receive communication. 

They will not receive a communication through Wordfly, so my biggest frustration is the over-inflated numbers in my extractions, and falsely promoting something to a constituent record when they have not in fact received it.

I would love to know how this is going now it is implemented.

Sure, it seems to be working just fine.  Our general move to Contact Permissions is treating us very well: it has radically improved the process of assembling mailing lists.

We had a "hiccup" when it came to my plan to eliminate the "unsubscribe" button in favor of being sent to a Contact Permissions page, which is that we do have a not-insignificant number of accounts in Wordfly that are not in Tessitura, and therefore can't have Contact Permissions set for them, so we do have to continue to offer unsubscribe.

Since implementation we've had a number of emails flagged for both hardbounce and for unsubscribe.  It is instructive to see that a great many more customer accounts that distinct email addresses: that it to say that in a number of cases we are finding the email associated with the action on more than one account.