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?
Hey Chuck!
Great questions and responses to date!
I would suggest that spousal relationships are different because of the assignment of benefits. In most cases the couple will share what benefits are received. However, there are times when they may need to split them - such as in the case of a divorce.
In the end I would think that the mechanics of connecting spouses would be the same as any other relationship connection. However, there needs to be a way to attach rules to the connections. With different rule sets we might be able to affect different results of the relationships on an as needed basis. We could also make one or more of these relationship rule sets apply by default.
For example,
An organization could establish the following relationships...
Spousal: Married persons - legally married - two or more persons (to accommodate changing values within society at large)
Parental: Connection between parent and child. Could include type attributes to indicate step or natural child/parent.
Sibling: relationship connection between two or more people. Again, could include a type attribute to indicate step/natural relationship.
Our organization could chose to establish a rule that whenever a spouse conducts a transaction that has benefit or value, the other spouse(s) get a benefit assignment of equal percentage value. If two people are married and person 1 buys a subscription, then person 1 and person 2 both own half the value of the subscription. Ignore the issues of who gets to sit in what seat for which performances for now.
Because this assignment is rule based we should be able to change the rule. Either globally or in a one off situation.
The point is that there becomes a difference between the mechanical process of connecting people and flagging those connections with attributes that indicate the why of the connection, and the rules that govern how business processes are affected by these relationship(s).
In such a structure the answer to your 3rd question would be that there would be no need for a name1/name2 construct and that at it's core a relationship is a connection between two or more individuals (or more generically - entities that have an "account") or one or more specific reasons. The reasons could be defined by the organization as could the rules governing variances in transactional processing dictated by the relationship(s).
Perhaps it would be best to just start with the basic need to connect these entities for a reason and then build scenarios around the rules that would govern transactional processing related to the relationship types.
Whew!