Re https://support.wordfly.com/hc/en-us/articles/217001566-About-duplicate-addresses
I'm interested in solving a problem with distributed email accounts.
To unpack: often we send out invitations to events via WF. A substantial proportion of these invites are to artists and creatives that are managed by the same agent with a single email address/point of contact, or less frequently to corporate partners that share a distributed email account.
The issue is that at present we need to choose a single recipient and then forward the rest by hand. Wondering if there is a more elegant solution AND whether this could be a problem with pages results reporting to Tessitura as I believe that in WF subscribers are identified by email address and can have only one CRM ID but in Tessitura the single point of ID is the CRM ID and they can have multiple emails. Many-to-one/one-to-many issues.
In regards to the emailing perhaps batching the campaign would be possible (if equally labour intensive). Wrt the WF Subscriber data I'm at a loss.
Best,Heath
Hi Heath,
This issue isn't specific to WF - P2 has it too and (from my research) so do most emailing tools (Mailchimp, etc) consider the email address as the unique identifier and will only send once to each email address to prevent the campaign (and its sending org) to be spam. We have this issue with some of our industry contacts (particularly agents) preferring to use generic email addresses - such as info@someorg.com.au.
I too would be very interested to see if there's an elegant (not too time consuming) solution!
Martin
Back when I was invites guy I'd try and go for the most specific agent/artist relationship to get more coverage (or email the performer directly). For pages though I should test myself out with two accounts having the same email as the CrmSubscriberId is passed through as the identifier from Tessitura's customer_no field it should map ok. That way sending batches or might work
I ran into two equivalents of this several years ago:
As suggested, the form can request all the name and contact details so that the RSVP can be eventually processed correctly, but I feel like it's still odd/confusing overall to have RSVPs record to a specific account that is not the attendee. (Since multiple responses can be recorded per constituent, it's not immediately an issue for the response action itself, just the results being practical.) ...I just stopped considering Pages an RSVP option for situations where the response was not reasonably limited to the recipient.
In terms of the email address, the Tessitura data geek in me of course screams that this is where all the iterations of CPP come in and maybe it's possible to pry a real address out of the artists if promised it's used only for a very specific purpose...
Overall though, I'm inclined to call this as a problem belonging outside of the tech systems--even if you could send multiple times to an agent on behalf of a range of clients, you still need to be able to clearly coordinate who they need to reach out to. While a data merge of a first name would be a nice clue, someone getting X seemingly identical messages to individually forward is pretty funky. To me, it's first a human challenge: how do you connect with each representative about relaying specific info to specific people?
Well THIS is where it gets interesting though isn't it? (please shoot me down if I'm wrong)
Lets say that a Pages RSVP works as intended and writes to Tessitura
The eDM invite has the link to the RSVP Page with the parameter appended on that link pulled out of Tessitura passing through a single CRMSubscriberID aka customer_no.
That's to my point. An eDM pointing to a Pages RSVP or Survey uses the CRMSubscriberID as the identifier - not the email address, correct? That means the IDed Customer from Tessitura goes back to the same Customer regardless of email address.
The problem though is the email delivering that CRMSubscriberID parameter is that each eDM needs a unique email address to deliver it.
For anyone following this thread...
Heath and I are also chatting 1:1 to be all geeky and in the weeds on this. One of us can circle back to note any final brilliance here, should some appear. For right now, we're agreeing that this is not a natural fit to the functionality of Pages, or similar platforms, and thus no convenient resolution. I extend this broad-but-immediate takeaway to add a caution that it's essential to factor in the effort (and risk) involved in situations like this--itemize and assess what you're really after and what it takes to both get there and then maintain. (Hat tip to Russell Hires for posting this reminder in TN Developer Slack: https://xyproblem.info/)
In Heath's example, an extremely reductive synopsis of this is that you're either dealing with inefficient collection of responses or inefficient manipulation of email campaigns and lists. Are either worth it, or do you go back to square one?