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!
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.
Great example. I don’t get stressed out over this kind of dupe. Because it’s not obvious, and I accept that dupes are a fact of life. Managing them better is important to me. In this case, as John Smith becomes more involved with either (or both) the Ballet and Symphony, more pieces of his contact preferences “puzzle” will fall into place, and at that appropriate time, his records will merge.
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Amanda Freeman Sent: Thursday, April 15, 2010 3:26 PM To: Sheleheda, Nancy Subject: Re: [Tessitura Next Generation Forum] Sharing Contact Methods
From: Dan Taraborrelli <bounce-dantaraborrelli3098@tessituranetwork.com> Sent: 4/15/2010 1:49:49 PM
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.
This may not be an issue regarding ‘sharing’ information within a consortium. Even if the operator can’t see the information the system can. When you go to save a constituent record a match is attempted by Tessitura right there and then on information that can and can’t be seen. If you are entering data that is exactly the same as data already in the system why can’t the system reveal that information temporarily in order to assist the operator in deciding if it’s the same constituent or not.
David
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Dan Taraborrelli Sent: Friday, 16 April 2010 06:11 To: David Joyce Subject: Re: [Tessitura Next Generation Forum] RE: Sharing Contact Methods
From: Nancy Sheleheda <bounce-nancysheleheda3263@tessituranetwork.com> Sent: 4/15/2010 2:37:50 PM
Please consider the environment before printing this email.=====This message is intended for the addressee(s) named and may contain confidential information.If you are not the intended recipient, please delete it and notify the sender.Views expressed in this email are those of the individual sender and are not necessarily the views of the Sydney Opera House Trust=====