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!
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.
So much of what I experience over “merging” is really fear based… “what happens if we merge two people incorrectly?” It can be very paralyzing, and thus you’re stuck with an ever growing database of duplicates for fear of the mess you’ll create over a handful of incorrectly merged customers. So I totally get Dan’s point of view here… better merging (and un-merging) tools would go a long way in helping us get comfortable with merges.
But back to the original question… to share or not to share at least one piece of contact info. Realistically, in our consortium we would probably decide to share something, even if we didn’t have to. Our funders like us to be a unified voice in our community. BUT, if some consortiums want to share nothing, then they should be allowed to do it. John Smith’s email at the Ballet would be private to the Symphony. And the Symphony will set up another John Smith record. And if that 2nd John Smith record has the exact same email as the first John Smith record, then it would be appropriate for the auto merging to happen.
Nancy Sheleheda
Tessitura Application Administrator
The Pittsburgh Cultural Trust Consortium
803 Liberty Avenue
Pittsburgh, PA 15222
412-456-1387
sheleheda@pgharts.org
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Dan Taraborrelli Sent: Thursday, April 15, 2010 2:51 PM To: Sheleheda, Nancy Subject: Re: [Tessitura Next Generation Forum] Sharing Contact Methods
From: Chuck Reif <bounce-chuckreif3941@tessituranetwork.com> Sent: 4/15/2010 1:09:36 PM
You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!