Sharing Contact Methods

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.

~Dan

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. 

I'm with Rebecca.  I think its a bad idea to set things up so that duplicates are the result.  We do everything in our power to prevent dupes because they are such an inconvenience.

I like Chuck's idea of having at least one contact method that is required and primary and shared.   While I don't currently work in a consortium I can see the problems that would arise by not having a unique identifier for each account - not the least of which is duplicate accounts.

Dale

Please note that I hate duplicates as much as the next guy.  My proposed solution was that these duplicates would exist for maybe an hour until a scheduled job or its equivalent in Next Gen would automatically merge them.  You'd never even know they were there.

~Dan

hmm automatic merging - now you've really got me worried.

Sure, our DBA does it all the time.  Well, she makes a 100% match based on a certain number of criteria, does a quick spot check, and sends them all to be merged.  Really helpful for all those people coming in from the web who decide to create 3 and 4 accounts for themselves.

But I think that's the point.  "She makes a 100% match based on a certain number of criteria".  If you only have two names ("John Smith")   with no address, phone number, email address, etc., how can you just go ahead and merge them?  What data would you use to match on?

To the Orchestra and the Opera it just looks like two random "John Smiths" because they can't see each others phones and emails. From the backend, the DBA sees a perfect match.

If both records truly lacked any contact information we probably wouldn't merge them unless the history was so old that it really didn't matter if they're the same John Smith or not.

Here's a scenario: John Smith is at the window. Box office looks for John Smith in the system, sees only a John Smith with no (visible) contact info. Realizes he can't know if that's the same John Smith or not. Creates a new account, which includes John Smith's email because he provides it at that point in time. He doesn't give his phone info and box office forgets to ask. Meanwhile, in the backend, that existing John Smith had a phone number only visible to a different organization. It is the phone number John Smith-at-window didn't provide. Now there are two John Smiths, one with an email, one with a phone. They happen to be the same person and dupe accounts, but there's no way to know that until the day comes when John Smith adds either phone or email to the account that doesn't contain it, respectively. That might not happen. If  the phone number had been visible, then at that window encounter when the search turned up a John Smith, he could've been asked "is your phone number X?" and he would've said yes and box office would know it was the same guy, and the dupe wouldn't have happened. So it's a matter of whether that sort of dupe is as objectionable as more obvious dupes, or if it makes no difference to you that John Smith has his two separate accounts, one with a phone visible to org A and one with an email visible to org B, instead of just the one account, with both contact methods, each visible only to the respective orgs.

Agree.  As soon as John orders online with the Ballet they'll get his email and when he renews his sub with the Orchestra they'll get his phone number.  If this doesn't happen we'll have a dupe but at least we didn't give out this poor guy's home phone number to 8 other organizations when he only intended to give it to one.  

If you're not up front with the patrons about this they can get pretty ticked off.  In this scenario we put a much higher value on privacy than duplicate creation.