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?
And some random thoughts from me.
After a lot of soul-searching , we decided that we didn’t ever want two records for the same person or org, and we didn’t ever want two people/orgs sharing the same record. One person/org = one record, and do everything else with associations in some way – that’s nirvana. We haven’t reached nirvana yet, although Kim has just switched off the Org Contact constituent type, which is a major stepping stone along the Way.
You can sort of cope that way using Associations now, but that causes some stress, particularly for Dev persons, who really like to see relationships right there on screen, and leads into very messy ways of trying to associate particular addresses via particular types of association……
So we’re clearly in the “No more N2” camp, though after some full and frank exchanges of views in Chicago , I realise that not everyone agrees, and we certainly need a way to group particular significant sets of constituents together (like households or spice or companies or families or co-members), probably also with a way of marking some of them as subordinate within that set (eg special flags/ types of record for dependent children vs parents in a household set, so we can know not to address the rugrats directly.), and with a way to address the set rather than the individual constituent in some circumstances and not in others.
Really what we need is a way of associating and grouping individual constituents that is so flexible, generic, and intuitive, that it can deal, not only with every way that we currently need to build associations between people/orgs, as Chuck is asking us for, but also with every tricky new way that we’re going to think of as soon as we see what we can do with the new version, but that we haven’t thought of yet. And present the relationships in such a way that the Dev person knows exactly what’s going on, but the ticketing person doesn’t say ”..and how did you enjoy The Blue Room, Mrs Smith?”, when Mr Smith actually went with Someone Else.
Now that sounds do-able. Easy enough, Chuck?
Ken
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
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=====
Chuck, I agree and can't wait to read all the different points, concerns and problems people face with relationships. This was one of my favorite parts of the summit and I'm sure will be one of my favorite threads.
Ken, thank you for articulating so well what I kept tying to write all day and ended up deleting most of. Also, very interested in hearing offline how you got rid of the org. contact type.
Cheers!
Thought I had #8 covered with the intentionally gender-neutral wording. My sincere apologies if it didn't come through. You could substitute "partner" in any of the examples, certainly...
Erin
Cool! From the Chicago Summit discussion and this thread great design needs begin to emerge! Of course I would fully expect that Chuck and his design team already have some models in mind. However, it's completely appropriate to see what the membership thinks. So, some of these comments are just recapping or restating some of the other comments we've read so far.
I fell that the answers to Chucks original questions show that we don't want to build in any constraints that are not technically required.
Imagine that we move to a different environment where every entity gets its own record. If its a person, they get a record. A foundation gets a record. A school gets a record. Even a group can get a record.
Each of these entity records could be typed so we know what kind of entity it is. We would need to establish what the minimum base amount of data is that would be required to create one of these records. For example, we'd have to decide if we can create an entity record for a person with only a first or last name. If so, we'd have to come up with other identifiers to make this record unique.
Uniqueness would be a key concept for entity records. Every entity record would have to be unique with no duplicates allowed.
Transactions could be tied to an entity. However, we may need to build in the ability to split the value of the transaction according to both predefined and perhaps on the fly rules. However it's done, we will probably need the ability to assign value and benefits to one or more entity based on relationship rules.
Relationships could become the connectors that tie entities together. If we follow these ties we could get pictures of entity groups that have different functions. Again, a rules engine would need to be used to build the views according to organizational standards.
For example, the term "household" has been mentioned many times in this thread. What is a household? What relationships determine which entities can be tied together into a household group? Are spouses automatically part of a household? What about married people who live separately? If there are child records tied through relationship to a parent record should we assume that they are in the same "household"?
Why are we even concerned with what a "household" is? Is this for marketing and communications purposes? Are there other ways to do that?
Imagine again that in this model we establish location records that could contain an address of a particular type such as a private residence. The location or address records could stand on their own and also be tied to an entity in a similar way that entities can be tied to one another.
When you're communicating with a direct mail piece who are you trying to reach? Are you trying to reach an individual entity or a group of entities that reside at the same location?
If you establish the relationships between these records (entities and locations) correctly, you should be able to create a communication that is targeted to one or more specific entities, but only delivers one copy to a specific location. The salutation could also be manipulated through similar rules.
It looks like I'm rambling now so I'll summarize...
The greatest flexibility may come from keeping data elements grouped together at the most granular level possible. Then building mechanisims that allow us to link these grains of information togeather.
Perhaps not technically feasible. But it could be interesting to follow the concept through some modeling.
Question for Chuck...
Is speculating about the constructs of an entity record relevant? Or should we be focusing exclusively on defining scenarios of usage?
I like many of the thoughts that are coming through, thanks everyone! I think Ken and Dan are proposing some grear thoughts that are very much aligned with what I've been thinking as we've dealt with varied business needs in several organzations. Let me throw out two extensions to what everyone has said for further comment and thoughts. 1. Relationships - what if these relationshis were flexible, and could join multiple entities to an actual grouping? For instace, several individuals could be related to a particular Family, and that family grouping would have an ID# of it's own and be treated as a 'first class object' in it's own right. 2. What if you could link both an individual entity (person or organization) AND a grouping to transactions or orders or payments, etc? With the thoughts already expressd y others, this would allow you to identify the individual person or organization AND the capacity in which they are acting (the 'grouping/relationship entity) to any action in the system. It would seem to address all of the issues/needs raised by everyone on this discussion. The relationships become primary objects, after all, this is a 'Customer Relationship' Management system! Alan
From: Chuck Reif <bounce-chuckreif3941@tessituranetwork.com> Sent: 10/16/2009 8:30:12 PM
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?
To your question Dan, if you want to speculate on what a constituent entity might look like, of course that's fine--it's your forum and ideas are always welcome.
But as I think you surmised we're really interested in usage scenarios, especially those that we may not have thought about. And also in members' thoughts on whether a spousal relationship is somehow different. I have to say that we're loving the feedback that's been coming in!
Our plan is to come back with a draft model at some point. Following our broad brush strategy, that model will probably be very half formed and full of holes. But something that we hope will elicit more comments. Like nearly every other decision we will have to make in our design it will strive to be a balance between "nirvana" and "doable".
Alan,
Great point!
I was thinking of a situation where the grouping of relationships could be built on the fly. However, our rules may demonstrate that some relationship groupings would be commonly used, and could have attributes of their own. Thus the relationship becomes a record itself so that those attributes could be tracked and maintained.
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.
Exactly!
From: Alan Levine <bounce-alanlevine7254@tessituranetwork.com> Sent: 10/20/2009 8:50:39 AM
Another answer to #3...
We need to also address how people use their personal assistant/secretary. Those people have a number of the same "powers" that spouses/partners have.
Honestly, I'm concerned about the concept of "split" values in general. I was thinking about how people describe themselves. "I'm a donor" and "I'm a subscriber" are pretty typical - the next step is to say "I'm a $1000 donor" -- which BOTH the husband/wife will tell you. Each spouse will take full credit for the entire amount - either on the phone, or in person.
I know that we aren't in a design phase here, but when you "split the value" - will Tessitura reflect that "value" as the husband is $500 and the wife is $500?? I can see a number of pitfalls with this approach that we should be aware of moving forward. The last thing any of us want is to navigate ourselves into a field of landmines as we use our sparkling new CRM system... telling a donor once by mistake that "the system reflects half" (or whatever) of what they think that they gave will not be pretty. Especially if it is one person's money.
Maybe I am missing something, but I don't get this part, or maybe I'm not buying =) Thanks for any enlightenment out there -
Erin,
You have gotten me thing about an interesting point.
One Memberships can cover a range of associated constituents. In our organization we have some memberships that cover just a single individual. In other cases we have a membership that covers a set of spouses / partners and offspring. The constituent association model has to be able to have a variety of relationships and the membership model needs to use these associations correctly to document different kinds of memberships. Finally we have to make it very easy to setup and use for our internal users of our system and web site users of the system. Hmmmm…. A big challenge.
which BOTH the husband/wife will tell you. Each spouse will take full credit for the entire amount - either on the phone, or in person.
| 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?
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.