One of the big tasks ahead in the Next Generation project is redefining all the ways in which a constituent relates to other constituents. Today we call this Associations and we know that it doesn’t begin to cover all the bases. So just as we have in the past, we need you to help us out with your thoughts on any or all of the following questions:
1. What are the ways that constituents relate to one another, particularly ways that aren't so easy to track in Tessitura today? 2. What are some scenarios that describe ways that your business needs to communicate with different segments of related constituents? (A simple example: “Sometimes I need to send a mailing out with only one piece per household. But if I’m doing the same promotion in an email I need to send it to all the members of the household.”)3. One of the things we struggled with in designing Tessitura the first time was the whole name1/name2 construct. Is there a reason to treat spousal relationships differently than any other type of family/household relationship? 4. What other questions need to be asked about this topic?
Chuck,
I have one audience member perspective on your question 3.
The name1/name2 structure has caused me confusion at the box office several times. My spousal equivalent Sara and I are a couple in several constituent records across different organizations. Sometimes she is name1, sometimes I am. When either of us buy will call tickets from one of these organizations, the tickets are held under the name of name 1. We have different last names, so this leads to confusion and delay at the pickup line. The box office staff member asks "What name are the tickets in?" One of us gives the name of the one who bought the tickets then is frustrated to find the tickets under the other name.
It's not a crisis, but it is a case where the system is making something more difficult to do rather than easier.
Somewhat more seriously, we encountered a case where our separate constituent records had been merged into one. Sara used the "Forgot your password" feature of the organization web site and was emailed my login credentials. Now, we've got the kind of relationship where this wasn't serious, but there are people for whom this could cause all sorts of chaos.
These experiences make me lean toward one person per constituent with data structures to deal separately with:
1) Means of communication that may be shared by several individuals (particularly snail mail, but some groups of people may share email addresses as well.) These data structures would allow rules to be set up for which instances of communication would be sent to each individual through private or shared channels. Shared channels of communication should have the ability to be separately named - e.g. The Davis Family, Our friends at 1222 S St NW. A particular social networking entity which had a large number of fans or followers might also be viewed and managed in the system as a shared means of communication.
2) Permission for agency that may exist between several individuals. Other participants in this thread have already pointed out cases of constituent record sharers being treated as agents for each other. Recognizing agency relationships between individual constituents rather than within a two person record would also make it possible to accommodate agency relationships that span more than two people.
3) Participation in a subscription with other individuals. Other participants in this thread have given good examples of cases where multiple constituents want to be viewed as a single subscription for purposes of seat location. Changing the data structure to individuals participating in a subscription would also simplify the which party in a divorce gets which seat issue. Seats would be nominally assigned to individuals within the subscription grouping. While the individuals continued to participate in a shared subscription, the tickets would be processed as a unit, but if that participation relationship later changed, they would be individual subscriptions again.