Lots of great feedback here on Contact Methods and managing communication preferences. On to a slightly more weedy problem. ("Weedy" is what we use to refer to an issue that doesn't involve grand visioning and is more, well, in the weeds.) The issue at hand is sharing contact methods, particularly in the consortium world.
In the current application every constituent must have a primary postal address that is shared. On the other hand in the current application you needn't have any shared phone numbers or shared email addresses. But at least each constituent has a postal address that everyone can see.
In Next Generation we realize that requiring every constituent to have a postal address is not viable and so we've taken that requirement out. In its place we currently have a rule that if a constituent has one or more postal addresses, then one of those addresses must be primary and shared. This decision was worked through with the ESC that worked on addresses.
And now we come to email addresses and phone numbers. (I know that there are plenty of other possible communication methods, but let's use these for examples.) So let's say we have constituent "John Smith" with no postal address, but with one email address that we got when John bought something on the Ballet website.
Should we require that this first (and only) email address be shared as well? If not, we've got a "John Smith" constituent in the system with a ballet email address only and someone from the Symphony will potentially have no way of contacting John, nor any way of knowing anything more about John than his name. What happens when John comes up in a search at the Symphony? The Symphony would have no way of knowing what John Smith they were looking at.
What do you think? We could make email addresses and phone numbers work like postal addresses--if a constituent has any, then one must be primary. Or I suppose we could have a rule that one contact method among many (i.e. address, phone, email) must be required and primary and shared. If we go that route, what's enough shared information to make John Smith identifiable by all users? His Twitter account? Or are we really talking about the standard postal, email and phone types?
Any thoughts, especially for consortium members would be welcome!
Hi Chuck,
We don't share phone numbers or emails in our consortium. If we lack an address we fill it with place-holder information, such as a zip code of 99999. We have procedures that mark these as invalid address types so they're never included in mailing lists.
Basically, I don't see the problem of having zero shared information. If all we have is a Ballet email for "John Smith" and the Symphony wants to sell him a ticket, well they'd probably end up creating a new account for him. That's when a Sys Admin (who can see all) matches up the exact name and email addresses from the backend and sets up the merge.
Instead of thinking about what is shared and what isn't I'd like to see better handling of duplicate account management. It's going to happen anyway, even if all data is shared. If the software can accurately match names, phone numbers and/or email address combinations across all consortium members, present them to you for review and give you a big MERGE NOW button, well then it doesn't really matter what "John Smith" we're dealing with.
~Dan
well then it doesn't really matter what "John Smith" we're dealing with.
But then you've also got the opposite problem. The day someone assumes he's got the right John Smith, when in fact he does not. And then instead of having a dupe you've got two totally different Mr. Smiths whose history is now in the same account. That's bound to happen occasionally anyway if we're talking same-named people with minimal contact info. But seeing contact info that exists could help prevent that from happening. It's almost worse than mis-merged accounts; at least then one can see that at some point they were separate and try to unravel it. This gets even more complicated once there is a duplicate for one of these two John Smiths, and it gets merged into the account that they've both had tickets under...
Not that I have a solution to that problem. But it seems it will increase the less visible contact info there is.
Good point, but I would never assume I had the right "John Smith" if all I could see was his name. Maybe it's about creating a new policy within your organization like, "when in doubt create a new account." Then, if you've got above-average merging tools at your disposal, they should be able to catch and nuke these dupes.
Sorry, Dan, but every fibre of my being rebels against the idea of allowing duplicates to come into the system when they could be avoided. We have well over a million records in our consortium and identifying and merging dupes is one of our biggest headaches. Therefore, while I STRONGLY support your call for above-average merging tools, I would say that it is vital to have at least one identifying piece of information that is shared. I don't mind whether this identifying information is address, email address or phone number, or one of the endless possibilities that will no doubt come up in the future.
Sorry, Dan, but every fibre of my being rebels against the idea of allowing duplicates to come into the system when they could be avoided.
We have well over a million records in our consortium and identifying and merging dupes is one of our biggest headaches.
Therefore, while I STRONGLY support your call for above-average merging tools, I would say that it is vital to have at least one identifying piece of information that is shared.
I don't mind whether this identifying information is address, email address or phone number, or one of the endless possibilities that will no doubt come up in the future.