Relationships, anyone?

Hear, hear!

But even what a constituent is needs to be thought through. Think about e-mail addresses. A particular constituent, let’s call her Lucie, likes to get e-mails from FGO both at work and at home, at two different e-mail addresses. Currently, we need to create two Lucies in the system. What if both of them buy tickets? Give gifts? Volunteer? So, really, eaddresses need to be semi-independent, perhaps attached via association to a constituent.

Lucie

--------------------------------

Lucie Spieler

IT Development and Training Manager

Editor, Season Program

--------------------------------

Florida Grand Opera

8390 NW 25th Street, Miami, FL 33122

Phone: 305-854-1643 x 1521

Fax: 305-856-1042

Ticket Office: 800-741-1010

www.fgo.org

A couple of thoughts that hopefully won't drag to topic too far off topic.

I'd like to enter another vote to do away with the n1/n2 format of the constituent record.  There are too many opportunities for unique processes or unusual constituent relationships that make n1/n2 awkward.  Especially when looking at trying to merge duplicate records without losing historical data. One name per record in t_customer is a much cleaner method.

Which brings us to memberships.  At the moment, the membership is a property of the constituent.  I would love to see this reversed.  Meaning that you could attach many customer records to a single membership entity. This is similar in my mind to the earlier posts about creating groups of constituents.

Yes, and/or….

there is a Relationship between Patron A and B (could be any “type” of relationship  -- spouse, brother/sister, friends, anything).   This could be one of many relationships that Patron A belongs to, and one of many relationships that Patron B belongs to.  

The Gift is attached to this particular Relationship (and thus both Patron A and Patron B), and the payment(s) is/are attached to that relationship as well,  or if they each paid a portion separately, each payment is attached to both the Relationship AND the particular individual who paid it.  

As Dan points out, this allows both views – via either individual, or via the Relationship.   It jives with Levi’s post as well, and also accommodates Pete Miller’s comments.     Just one of many potential solutions though.

Excellent points Erin,

I think what some of us were getting at is this...

The system needs to be designed in such a way that rules can be configured to determine if the value is automatically split and if so how.   There may be circumstances where an organization wants to do this.  Then again, there may be times when you don't.

The transactions could be recorded at the lowest level of granularity.  Yet the view of these patrons that is filtered by the spousal relationship and a custom rule that gifts in spousal relationships have shared value would allow you to get what you want.

Put another way...

Because we currently have a joint account model we think of the need to "split" the records to share them.

Instead, think of the records being split from the beginning.  The need then becomes to find ways to join the records and in some cases the values of the transactions when viewing them.

Let's see if we can flush out the individual entity records and relationship records concept with your scenario.

Patron A has an individual entity record.  So does patron B.  A relationship record exists that indicates that Patron A and Patron B are spouses, and a rule exists that indicates that they choose to jointly share the value of their giving.

In this case anytime you query the system for the value of gifts given by Patron A, it would also include Patron B's giving.  So, if Patron A wrote a check for $500 and Patron B wrote a check for $1,000 a query for the giving level of either of them would indicate that they have given $1,500.

However, the fact that Patron A gave $500 and Patron B gave $1,000 would also be captured.

You retain both views.  The fact that they gave individually through separate checks is captured.  The reality that you want to know and report what they gave collectively is realized.

I’m thinking that relationships would become much more important in Tessitura of the Future. There could be a screen (probably part of associations) where we could check off whether to associate ticket history, memberships, gift history, or anything else. These associations would each need date ranges and auditing of changes. If two accounts had their ticket history and gift history associated, any gifts made by one would accrue to both (showing up green in the other’s account). Perhaps you could set up a default category such as “spouse/partner” that, if selected, would automatically create all sorts of “sharing” associations between two constituents. A gen sal button on steroids!

--------------------------------

Lucie Spieler

IT Development and Training Manager

Editor, Season Program

--------------------------------

Florida Grand Opera

8390 NW 25th Street, Miami, FL 33122

Phone: 305-854-1643 x 1521

Fax: 305-856-1042

Ticket Office: 800-741-1010

www.fgo.org

I think how the new model of constituents and relationships affects marketing, or more generally lists and extractions, is an interesting point.  In the interests of targeted communications, perhaps it would be good to have some way tracking who the originator of shared transactions is.  So if my wife and I have separate but connected accounts and share a ticket history, but she usually buys the tickets, you could use the originator criteria when pulling the list so you only get my wife on the list and send one brochure to my house targeted at the person who makes the actual purchase decisions.  You could apply the same concept to contributions.

It might also be helpful to have some more advanced parameters for choosing which names get output with your lists and extractions, so that if the same address shows up more than once I can select who at that address I’d like to talk to, individuals or combinations and what form the combinations take.  Maybe it could create combined name salutations on the fly when it recognizes an address shared by a certain relationship type rather than pulling preexisting salutations from the accounts.

Anyway, great conversation!  I’ll go back to listening now and getting excited about all your interesting ideas.

Kevin Sheehan

Documentation & Learning Resources Specialist

Tessitura Network

1 888 643 5778 ext 329 Office

ksheehan@tessituranetwork.com

Kevin,

This is exactly what I was referring to in the suggestion that you could attach the ‘relationship grouping’ (in this case the relationship that combines you and your wife) as well as the individual (in this case, your wife) to the transaction.    Thus you know the individual you are dealing with directly (your wife) as well as the capacity they are acting in (as the representative of your marriage relationship grouping, so to speak).   I also really like  Dan’s idea of a definable rules-base for intelligently handling communications such as email and direct mail based on various pieces of information such as the type of transaction and the relationship object involved.

Here is a more comprehensive, and very real-life, scenario:

John and Jane Smith are married.   They attend the Theater series together with a subscription, arranged for and purchased by Jane.  

Jane is also friends with Janice.   Jane and Janice have a Dance Series subscription together, also arranged for and purchased by Jane. 

Janice and her husband Jim have a Symphony Series subscription together, arranged for and purchased by Janice.   

Jane also is a donor via an annual Membership she shares with her sister Denise, who lives elsewhere but visits often.   Janice made the original pledge, but Denise sent in the payment.

John and Jane have  two children, high school students, who are member of the Student Discount Program, and they can bring up to two additional people with them to any show at the discounted prices.

John, Jim and Jane also all happen to work for the same company, ABC Limited, Inc.   That company is a corporate fund donor, which entitles their employees to be invited to two dress rehearsals a year.

The need is to track each of the subscriptions and memberships and know who they belong to, who paid for each, who the primary contact was for each, and who should receive communications such as renewals regarding each.      Being able to track the individuals, as well as the ‘relationship groupings’ they are members of, and the transactions associated with each, would address many business needs.  

Knowing all the individuals and organizations that belong to each relationship grouping, and conversely, all the relationship groupings that each individual/organization participates in, would be tremendous.    It would of course be great to have tools to gain visibility into these ‘personal networks’.   For instance, Jane is clearly an ‘influencer’, and a good target for marketing.     There is much ‘science’ available for understanding, visualizing, and capitalizing on an understanding of these personal ‘networks’, and this would be useful knowledge for Tessitura to  build some really interesting features around.

Alan

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

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?