Relationships, anyone?

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?

Parents
  • Former Member
    Former Member $organization

    If you get serious about the “relationship entity “ (or ”group constituent” or “constituent Set” or “relationship grouping”) idea, I think you definitely need to follow that through to having the relationship entity time-based.

    It’s true about all relationships and associations, really, whether they’re personal or business or whatever. Jane is a member of this group consciousness for a period, just as she may be an employee of Big Corporation, and do some business with us under that relationship, and then next week she might be working for Small, LLC, and buy some tix for their staff party. If the relationships aren’t time-defined, when we look at Jane’s record, we just see both relationships, and we don’t know which one is current, and if we look at the relationship entity record, we don’t see that it’s defunct. And just marking them as current or not isn’t enough, really, if you want to keep track of what you’ve done.

     It’s not so much the relationship entity that’s time-defined, though, as it is the individual’s membership-of the relationship entity, so if it’s not a binary type relationship (or even if it is, I suppose), different constituents could slip in and out of it as time goes by. Which of course raises the possibility that you could end up with a relationship entity with only one member (Narcissus has no friends except himself), or which exists and has history but has no members. (An interesting question, ontologically speaking – can a relationship which has no members rightly be said to exist? Discuss. Papers due end of term.)

     

    Managing relationships in that depth emphasises all those existing privacy questions in a consortium environment, of course. If Jane tells Bell Shakespeare that she and Janice have moved in and are now a couple, will Janice be surprised to find out, when the Opera send them a subs brochure, that they also already know? Will she be cross?

    But that’s another question, I suppose, and I fear a completely intractable one, whereas this one is just fiendishly difficult and interesting.…

     

     

    Ken McSwain Business solutions Manager

    kmcswain@sydneyoperahouse.com

    T+61 2 9250 7876  F+61 2 9251 7821  M 0418 659 360

     

    SYDNEY OPERA HOUSE BENNELONG POINT

    GPO BOX 4274, SYDNEY NSW 2001, AUSTRALIA

    SYDNEYOPERAHOUSE.COM

     

     

    From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif
    Sent: Wednesday, 21 October 2009 14:34
    To: Ken McSwain
    Subject: Re: [Tessitura Next Generation Forum] RE: Relationships, anyone?

     

    Just some further thinking to get feedback on. If you were to go down the path of tracking every transaction to both a "relationship grouping" and to an individual constituent, then my assumption would be that you would have to track the relationship as a time based entity as well, right? In Alan's example, Jane is friends with Janice and Jane purchased a Dance Series subscription for both of them. So we have a Jane entity, a Janice entity and a Jane/Janice friendship "relationship grouping". But Jane and Janice have a falling out after the subscription is over and you change the relationship between the two, then you need to remember that for some period of time they were friends? Or if they get married, and now have a spousal relationship, do you need to still have the "friend relationship group"? Otherwise you lose the reason that they attended the dance subscription together.

    I know that there was a lot of talk about this in Chicago, specifically dealing with the divorce/child custody/blended family type of tracking.

    How far do we take this sort of thing?

    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=====
    
Reply
  • Former Member
    Former Member $organization

    If you get serious about the “relationship entity “ (or ”group constituent” or “constituent Set” or “relationship grouping”) idea, I think you definitely need to follow that through to having the relationship entity time-based.

    It’s true about all relationships and associations, really, whether they’re personal or business or whatever. Jane is a member of this group consciousness for a period, just as she may be an employee of Big Corporation, and do some business with us under that relationship, and then next week she might be working for Small, LLC, and buy some tix for their staff party. If the relationships aren’t time-defined, when we look at Jane’s record, we just see both relationships, and we don’t know which one is current, and if we look at the relationship entity record, we don’t see that it’s defunct. And just marking them as current or not isn’t enough, really, if you want to keep track of what you’ve done.

     It’s not so much the relationship entity that’s time-defined, though, as it is the individual’s membership-of the relationship entity, so if it’s not a binary type relationship (or even if it is, I suppose), different constituents could slip in and out of it as time goes by. Which of course raises the possibility that you could end up with a relationship entity with only one member (Narcissus has no friends except himself), or which exists and has history but has no members. (An interesting question, ontologically speaking – can a relationship which has no members rightly be said to exist? Discuss. Papers due end of term.)

     

    Managing relationships in that depth emphasises all those existing privacy questions in a consortium environment, of course. If Jane tells Bell Shakespeare that she and Janice have moved in and are now a couple, will Janice be surprised to find out, when the Opera send them a subs brochure, that they also already know? Will she be cross?

    But that’s another question, I suppose, and I fear a completely intractable one, whereas this one is just fiendishly difficult and interesting.…

     

     

    Ken McSwain Business solutions Manager

    kmcswain@sydneyoperahouse.com

    T+61 2 9250 7876  F+61 2 9251 7821  M 0418 659 360

     

    SYDNEY OPERA HOUSE BENNELONG POINT

    GPO BOX 4274, SYDNEY NSW 2001, AUSTRALIA

    SYDNEYOPERAHOUSE.COM

     

     

    From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif
    Sent: Wednesday, 21 October 2009 14:34
    To: Ken McSwain
    Subject: Re: [Tessitura Next Generation Forum] RE: Relationships, anyone?

     

    Just some further thinking to get feedback on. If you were to go down the path of tracking every transaction to both a "relationship grouping" and to an individual constituent, then my assumption would be that you would have to track the relationship as a time based entity as well, right? In Alan's example, Jane is friends with Janice and Jane purchased a Dance Series subscription for both of them. So we have a Jane entity, a Janice entity and a Jane/Janice friendship "relationship grouping". But Jane and Janice have a falling out after the subscription is over and you change the relationship between the two, then you need to remember that for some period of time they were friends? Or if they get married, and now have a spousal relationship, do you need to still have the "friend relationship group"? Otherwise you lose the reason that they attended the dance subscription together.

    I know that there was a lot of talk about this in Chicago, specifically dealing with the divorce/child custody/blended family type of tracking.

    How far do we take this sort of thing?

    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=====
    
Children
No Data