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.