Hey fellow e-nerds,
Just wanting to float that evergreen topic of Permissions as no matter how many times it's brought up and how many hours it's talked about I always seem to be left wringing my hands and pulling sobbing into my keyboard.
So I'm looking at Contact Permissions (with Interests) and the Contact Permissions Plug-In. More background listening here https://www.tessituranetwork.com/en/Items/Videos/Webinars/2017/GDPR NB/ I'm leaving aside Contact Point Purposes for mental health reasons.
Business Need
We have a need to take separate customer Opt-Ins for venues we perform at and presenters that perform at our venues, separately to our shows. We need those options to be dynamic depending on what is in the cart. We're also interested in separating our Philanthropy and Marketing Opt-Ins with philanthropic comms opt-in being offered when a donation is made.
The Contact Permissions Plug in does that with bells on which seems like a win.
Other preferences
We have other parts of the business like our Dance Academy, Youth Workshops and Dance Classes which we can manage as Interests well enough.
Pain
My difficulty is what does a WordFly Optout mean in this situation? A global opt out is a requirement so when someone opts out of everything where does this happen? The party line for both Tessitura and WordFly is "Only use Permissions as a Global Setting" but that would seem to invalidate the whole Permissions Plug-In product that was developed due to a very real industry need. Letting people opt-in and out of business segments is a great idea but would seem to need another hierarchical level.
Has anyone managed to tease out that issue?
Thanks in advance.H
Hey Heath,
IMHO contact permissions should be your global opt-in - consider it as a channel eg email, SMS, phone, mail. Then use interests to manage anything granular underneath that for example a genre-based newsletter or philanthropy. You're using WordFly so you can bring across those interests as checkboxes on their subscription management page, and then update the local procedure for a global opt-out to turn off the contact permission (and potentially un-select those interests if your business rules make that so).
The exception to this is your presenter opt-ins which should definitely be contact permissions, triggered in the cart by the contact permissions plug-in for TNEW. Generally I've seen these used as criteria for lists to pass on the data to presenters/venues once the gig is done, rather than pulling them into your email platform in the same way an interest might be.
The complexity of all of this is of course the fact that in Tessitura the unique identifier is a constituent ID whereas in any email platform the unique identifier is the email address. Welcome to the stage Contact Point Purposes do sit at the individual address level. That said, they begin to become overly complex and unless you are totally on top of your duplicate management will become a very big headache.
Happy to talk more and pull apart my thinking :-)
dgh
Hey fella,
Thanks for this. I think I've teased out most of this and the historical context in which they were developed. For Importal integration it sits in a similar place to the list criteria. Is it correct that that even if they are not in the WordFly Preference Pages (with Marketing Email permission and Interests) they will all appear in TNEW new account and interest pages?
I think that the biggest confusion is the way that philanthropy and marketing have been pitched as separate permission channels in both webinars. I'm not sure that it is viable. One would have to chose which of these was was the sole source of WordFly global optout (likely Marketing) and treat the other as an interest making note that No to Marketing means no to everything.
Am I thinking about this the right way?
Regards,Heath
With the contact permissions plug-in you can choose which contact permissions are displayed, and where. For example you're not (usually) going to set up your presenter type contact permissions to fire on the account creation page, but would set it to fire on the payment page.
I see your confusion re: the webinars, I suppose I have a more "global" approach to contact permissions than others. I think the pursuit of being able to easily tell from a constituent record whether someone is opted in or not (eg by looking at a single email contact permission) is always going to be my preferred way of doing things rather than having to do some mental calculations or business rules that put a certain priority on one permission/opt-in/whatever over another.
You are 100% right about global permissions and to interface with the ecosystem partner (from what I can see) there has to be one.
For Permissions as a Global and Interests as the sub level preferences that makes perfect sense.
But by putting a branching number of options at the Permission Level (and that is what the Plug In does) you solve one problem (opt-ins dynamically by product) but create another (no global permission). Opt-ins by product are a very common issue, and because they are contracted it's not something that most of us can dodge around.
That seems to be why Interests, Permissions and Contact Purposes are a bin fire. They solve a piece of a puzzle but independently of the environment around them and can't be used with out a hack or particular business rules.
Hi Heath, I'm chiming back in here. As I mentioned in my response, we worked with Tessitura on getting our permissions set up. Originally, we were going to do a global option but later decided to use interests. It sounded like it was one or the other, however, I could have misunderstood. It may be worth opening a ticket with them to see if there is a customization to use both. They were able to do things for us that we couldn't because we are hosted and, therefore, don't have DBO-level access which prevented us/me from adding certain SQL scripts to the server. It will likely cost money but it could solve your problem.
Thanks Staci. I didn't have much luck getting a response from Consulting but I've put in another ticket with Support and will take it from there.
Heath Wilder said:But by putting a branching number of options at the Permission Level (and that is what the Plug In does) you solve one problem (opt-ins dynamically by product) but create another (no global permission).
Can you give me a use case for this? In my mind the presenter-type contact permissions are for internal use - eg, as a criteria to pull a list to send the data to the presenter or a flag for Importal to pick up on. I wouldn't expect those permissions to supersede your own global contact permission/s, particularly because when you're using the contact permissions plug-in the customer is going to be prompted to opt-in to the presenter contact permission. You are explicitly asking their consent for that permission type. Even if they have not opted in to your global contact permission, they could still opt-in to the presenter and you could happily share their data knowing they have consented to that.
I think that I know what I need to do pragmatically to make it work.
My problem is that it is presented in one way (Permissions should be global opt-ins) but there are quite a few exceptions. And the examples (philanthropy and marketing) compound that. Knowing that's the case though I've got a call in with support to follow up on some items.
Thanks for taking the time to go through it.