Hello! I'm curious how everyone is handling bounces and unsubscribes, from a contact permission perspective. Do you have that information synced between Wordfly/Prospect 2 and Tessitura?
My hesitation is that contact permissions apply to the constituent level. But many constituents have multiple email addresses. So it may be that only one email is bouncing, and/or they meant to opt out from a particular email address rather than their entire record.
However, because we don't have that information written back to their record from Wordfly, sometimes we are promoting emails to an account that won't actually receive it.
I'd love thoughts on this! I had asked around at TLCC this year and it didn't seem anyone had much of a solution, but perhaps there's something that's missing.
Hi Jean and all -
My main excitement about the switch away from permissions on the General Tab is that we will finally be managing all these details per contact point rather than per constituent. It should be a game changer in terms of the mentioned situation of someone having multiple addresses logged and simply opting out of one or more in an act of housecleaning rather than ending a relationship.
Because the required move from the General Tab into Contact Permissions and Purposes means that we have to update the syncing procedure between WordFly and Tessitura anyway, I'm intending for us to also invest in making sure it's executing the way we need in terms of categorizing addresses after hard bounces and in regard to multiple instances of the same address on a single record, across household:: individual records, and (of course) true duplicate records. Hard bounces, and anything more of a "bad data" logic, will get a categorization of that--Unsubscribe will be strictly held to mean "permission revoked," as legal compliance is a very different story than, say, a typo like .con taking an email out of your lists.
I've just closed a support ticket with WordFly related to this, and they've mentioned "Tessitura is currently developing a new default implementation of the stored procedure." Might someone from Tessitura expound on this? Even just a confirmation of intention and a heads up about when to look for news of it would be greatly appreciated.
Hi Jamie! I may not be totally following what you're saying here - but best I can tell in V16, the Contact Permissions work exactly the same, aka they apply to the constituent rather than the specific address or email.
This is my constituent record from our v16 test environment. So it's still the blanket "Permission To Email: Yes/No" which I find too broad.
Contact Point Purposes DO exist, which we haven't explored in part because it seems like Tessitura is urging us to move away from it.
Jean, I'm curious what makes you say that Tessitura is urging you to move away from Contact Point Purposes. I've been doing a lot of research into both CPPs and Contact Permissions recently as part of the upgrade to v16, but I haven't come across anything that indicated a preference for one or the other. I know Contact Permissions were added to meet GRPD requirements and to replace the restriction fields on the general tab, but so far everything I've seen seems to indicate that Contact Point Purposes best for opt-ins/out by email and by interest area (Newsletter, Deals & Discounts, etc). Has Tessitura said anything directly to your organization about going away from CPPs?
Hi Shelly! That's a good question. My takeaway generally from TLCC last year and other conversations is that the big move is TO contact permissions (away from the general tab), rather than a push to move from contact permissions to contact point purposes.
We are already using Contact Permissions, because we're a newer implementation (since May 2020).
I am more than happy to be wrong about this, though!
Yes, I agree that the big move is from Mail Restrictions on the General Tab to Contact Permissions, but that is not to the exclusion of Contact Point Purposes. Speaking broadly (others can correct me if I'm wrong), none of us have really used mail restrictions in a while, since, again, they applied at the constituent level rather than the email level. Tessitura doesn't want us to lose any historical data that may be living in the Restriction fields, though, so that's why the push to migrate to Contact Permissions. There's nothing saying that you have to use Contact Permissions for unsubscribes, though (especially if you're not in Europe). Contact Point Purposes may be a better fit for what you're trying to accomplish.
Hi all!
Contact Point Purposes are great in theory but have serious drawbacks and IMHO are not fit for purpose because they carry no audit trail and are either on/off. For example, if you are using contact point purposes for your email newsletters and someone does not have a specific contact point purpose on their email address - how do you know whether they have unsubscribed or were simply never subscribed? Contact point purposes are also not supported in TNEW out of the box.
Contact Purposes are a better fit because they can be set as yes/no/not asked, the interface shows the last asked/updated date and they are supported out of the box in TNEW. However as you all have already said, because they sit at the constituent level, they don't accomodate a constituent that has multiple email addresses and may want some email sent to a certain address and other mail sent to another address.
There is a fundamental issue with Tessitura and any email/web product in that the unique identifier in Tessitura is the constituent ID whereas any email/web product the unique identifier is email address or login. Until this is addressed, there is no out of the box fit for any of this.
DGH
perfectly put DGH!
Yes! such a challenge trying to navigate this. It takes up wayyyy too many hours of my week.
So well put, David! This at least makes me feel better about struggling to figure out a solution! Does anyone use Contact Point Purposes to denote something like "bounces?" In other words, when building a list or extraction, you could exclude an email with that Contact Point Purpose? OR, would that not work, because it would still suppress the constituent?
Jean -
Right now, I'm guessing we are both correct and DGH's commentary may explain why. My understanding--currently based only on recent work we did for SMS Performance Alerts and not yet email--is that while the Permission may not itself look connected to any particular address point, you are also meant tag addresses with usage details.
I hadn't caught on to the concept that this is a separate, second-ish action and things probably will generate in full without it. In other words, being all about a constituent RECORD rather than just the particular address. So, David Geoffrey Hall, can you help us out and confirm that this is (a) true and (b) this is the set of things that exist and we are trying to wrangle?:
And also the aforementioned Interests, and even Attributes, but at least those feel like fully a different thing.
Also, Jean, my working plan is to try to focus on the idea of "inactivating" an address for things like bounces or any type of 'this address won't reach the person' feedback. This may get torpedoed by that fact that inactive status can be tied up in "Primary" status, but my gut says that it's easier to understand if a 'doesn't work' label is a very separate idea from all the rest of this. It's not legal, it's definitely not about the constituent as a whole, and I think it will be easier for others to understand what they are looking at if the concepts aren't logged side by side looking the same to people in Tessitura.
Definitely interested in David's response here! At the moment, our Contact Point Purposes are out of the box and too broad (i.e. "Allow Marketing") so we aren't using them in a meaningful way. We just have the yay or nay permission.
But Jamie O'Brien, you did hit on one of the pain points - on the CPP level, you can't inactivate the Primary email, and you also can't inactivate or delete an email that has a login attached - which is tough if they have only one email and it's bouncing. So I really don't know how you automate it (i.e. via syncing) and even as a manual process it's cumbersome.
I'd be delighted if someone has a process to share that works here - I'd even buy them a cupcake!
I'm not the expert by any means... I just have strong thoughts about this area of the software!
The documentation includes a section on general recommendations, FYI - under the Data Locations section here. However it doesn't touch on many of the issues raised in this thread and is somewhat vague, but it does give an indication on how the functionality is intended to be used.
Jamie O'Brien I'm not quite sure what your exact question of me is sorry. But yes, Contact Permissions and Contact Point Purposes are meant to be the functionality that manages what we're all talking about, however each organisation deals with it in their own way - generally in my experience with a level of customisation... therein lies my main issue :-)
In the risk of an international imbroglio* there is a good pitch for a Contact Permission that acts as a global Opt-in/out and CPP/Interests for the rest.
Contact Permissions: So if you you have TNEW and want the funky Permissions AddOn I think you have to ask for it. But in my humble opinion it looks really worth it - especially if you have 3rd parties that you need to track Global opt-ins for (external hirers or venues you present at) then you can do that in the purchase path and only if it's relevant. I really wouldn't advice splitting your business segments that way though unless siloing those Brands is a business model (ie: House of Brands rather than Branded House). Those latter Permissions are sometimes called Performance Based Contact Permissions. Contact Permissions TN Webinar . Permissions came out later than CPP and Interests and are in response to a GDPR (and CCPA) world. If you think that you are not affected by GDPR is good to check in further to be certain.
Interests vs Contact Point Purposes: If you can map our the fractal pattern of CPP and you can write a customer journey to update that then great. I find that the number of people that are particular about which email/phone/address different things go to are a specific few that are often managed internally and the majority of customers that self manage have simple and clear comms pathways, but it's worth examining them as business segments and getting an ROI. WordFly can handle either (or all three) but you need to have sound logic.
It's worth ask your team about how you want to handle merging, and if someone opts out how they can opt back in again (WordFly has clear automation rules for that but your logic needs to be sound).
Just my 2c H* I really just wanted to use imbroglio in a sentence