Relationships, anyone?

Hi Chuck - i have a few thoughts to add on assocations:

1.       The way are displayed is makes it difficult to read and they are not easily searchable (i would suggest a list of names and relationship types that you can click into)

2.       They should be listed alphabetically by organization/surname

3.       Contact information needs to be stored in an organized way especially for corp/trust contacts who don’t have their own records

4.       They don’t necessarily need to be divided into employment/family/other as this can be defined in the exact nature of the relationship

5.       You should be able to invite associations to activities

All the best,

Ruth

As Ray noted, family relationships are problematic for the Science Museum as well - not only children to parents but also to grandparents (since Grandma and Grandpa have a membership that covers their entry) and to friends and neighbors (since they may only sign up for a class if they can take it with a friend and we need to know that it's ok for them to ride home with Susie's mom). 

Schools to teachers is another complicated relationship because one school has multiple teachers and teachers often change schools, but we still have a need to see the big picture of how many times a school has attended as well as the small picture of which specific teachers are bringing groups to us and if they have a personal relationship with us as well.

Another question around this subject that I see as important is: What function does a relationship perform?  Do they confer some sort of benefit?  Are they simply for tracking purposes?  Can one relationship do something different than another relationship?  A business need we have is for a way to sell a membership that included a 3rd named adult whether it is a live-in grandparent, nanny, or college-age child.  This relationship would need to be trackable so that we can confer benefits and watch renewal trends, but in other ways we may need to treat this person as a separate individual.

The spousal question is a tough one.  I do see value in tracking how related groups of people interact with the museum, but perhaps some way of defining a 'household' would be of more value since the spousal relationship is a very small part of this.  The important part, to me, is knowing who belongs together and making sure we are identifying, tracking, and marketing to them correctly.

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!   

Just a quick follow up question on the membership relationship that was described.  Suppose I buy a family membership and the membership is for myself and my friend, Tom.  Then Tom buys a family membership for himself and his grandchildren.  What is Tom then?  A member twice?  How do you count him? 

It's an interesting concept because you might almost say that there is a Chuck/Tom constituent and a Tom/grandchildren constituent for purposes of this membership but it starts to get a bit confusing!

I'd like to focus on your #3 about a "spousal" relationship. A spousal relationship is already treated differently than other family/household relationships - in both subtle and straightforward ways. This is really important and this is a long answer. And these are only my initial observations =) Some examples and some thoughts:

1) The wife calls and expects us to know who her husband is - she might even use his name in identifying herself to us. "Hello, it's Mrs. Bond. James Bond." We have to be able to find her (Hello Sasha) and confirm her relationship to him as a person who is "qualified" to make ticket exchanges, make ticket donations, etc. on the account of James and Sasha Bond. Other family members will call and say, "I'm calling on behalf of my sister Sasha Bond."

2) Spouses are automatically "qualified" to do a multitude of things that other family/household members are not necessarily able to do. Charge things to each others credit cards, ask for payment receipts and duplicate tax reciepts, request seating changes. Inquire about the status of requests and update the requests -- "James told me he asked for box seats, I don't like being that far back. Put us in the front row. He will be happier there. You have the visa ending in 0077? Charge that card for the upgrade."

3) The types of comments and observations we record about patrons are applicable to both spouses, or not. "Wife loves education. Husband loves opera with a beautiful soprano in the lead role." I might pitch them a sponsorship where a beautiful cast member hosts an education program (so long as I read the comments somewhat in proximity to each other and can make the connection.) On the flip side - "The Bonds are great additions to any table. They can converse in three languages and have homes in a variety of winemaking regions around the world." These comments apply equally to both spouses.

4) A spousal relationship is a legal one. What's Husband's is Wife's and vice versa - this leads to lots of behaviors that operators can/can't, do/don't, and will/won't do. As I think about it, most of our internal processes are set up to ensure that subscriptions are retained by the same couple, and that payment transactions/contributions are correct. For instance, Suzy can't access her account via the web, and delete Jack, then three days later request duplicate receipts for all the donations that "they gave" with only her name on them. Ditto for Jack crossing out Suzy's name and adding someone else's name when he returns the payment for subscription tickets. All sorts of red flags get thrown up.

5) Tax receipts are sent with the name(s) on the account to the address on the account - we let the couple take it from there in terms of "who" gets the tax deduction. If the $$ came from a check with only the wife's name on it, we put it into the account of the couple, and if the wife does her taxes separately and is going to take the deduction, fine, and completely not our business. But husband and wife both get acknowledged for the donation (if they have their program listing set up this way) - they both get invited to everything that they qualify for, etc. We wouldn't start sending invitations to donor events with just the wife's name because the wife charged a contribution to her credit card when there is a long history of the couple's support of the opera.

6) Subscriptions are in both account names. We don't assign the aisle to Husband (N1) and the inner to the wife (N2). This becomes an issue for spouses when there is a divorce (sigh) or if one spouse dies and the surviving spouse wants to give up one seat, in which case they usually keep the aisle. This point about ticket assignments cannot be overlooked or minimized for performing arts orginizations. The spousal relationship supercedes our ability to arbitrarily make a ticket location assignment for multiple seat subscriptions in particular. I could really get into this example, but will stop here for now.

7) Husbands and wives frequently use each others credit cards and we store them on the account. If Husband calls and wants to use wife's credit card - especially if it is a couple that use different surnames - we can see that the credit card is ok, etc. and move ahead with the transaction.

8) Finally, though it seems a little obvious, a person is only the spouse of one other person. That to me makes the relationship both different, and special.

Hi Chuck,

I guess this is kind of in response to question 3.
As you know the whole name1/name2 debate was a big part of the Chicago summit
and I think most of the problems we found with the multiple relationships which have been mentioned in this thread like parent/child, spouses, partners, ex-spouses, custody, individual/employee/employer, business/business branches or locations etc. etc. we all (I believe) agreed could possibly be solved by dropping the n1/n2 model replacing it with a single constituent per record model that would be able to reflect our whole relationship with the constituent regardless of it being spousal, household or employment related. Obviously there would be lots of inherent questions and problems with this that would need figuring out, both on a technical level and on a relationship tracking level (tagging the relationship to a record and what happens to these records and tables in a divorce etc.) but I think we all felt that we were headed in the right direction with this type of account concept and I think a lot of the questions asked and some ideas about how to go about this were hopefully captured on tons of little post-its.

Fear not--we absolutely have all of the output from the Chicago Summit meeting captured.  But this is a huge topic and we wanted to make sure that all members had a chance to weigh in, whether they were in Chicago or not.