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?
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
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Kevin Sheehan Sent: Tuesday, October 20, 2009 3:38 PM To: Levine, Alan Subject: RE: [Tessitura Next Generation Forum] Relationships, anyone?
You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!
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?
Just some thoughts using the Jane/Janice example, what if on a transactional and/or historical level when Jane and Janice buy the dance series it first creates a row in transactions notating that Jane and Janice have now become part of this relationship grouping almost like social networking sites and then each dance series record includes a tag indicating this relationship associated with them. Maybe we could click through on these records to the other constituent(s) or dig deeper on the records to see the constituent(s) involved in this relationship.Anyways, if that relationship ends and we remove that grouping the transactional and/or historical records would retain the past relationships but would now, like when it started include a row indicating the relationship has now ended.Poor Jane and Janice.But if there relationship changed into a partnership or marriage then we would see two rows, one indicating the end of the friendship and one indicating the new relationship.Go Jane and Janice!And if we have the ability to update relationships already assigned to transactions etc. maybe we find some intelligent way to update or append all those dance series records with the new relationship group.Having an audit trail also available that just lists the relationship changes would probably also be useful for quick reference.
Anyways, just some thoughts. time for bed.
Further thinking on "time based" records in general...
Part of the goal with any system such as should be to capture the state of data at a specific moment in time. If that data element has the potential to change over time, and it would be detrimental to lose the context of the data as it relates to the time in which it was recorded, you really have to also record the time.
This would be true in many areas within the system and would prove very useful.
This is just my opinion and I'm not a trained software designer. However, I think this concept should apply at a very high design level and widely across the board.
I know that there are cases where certain data elements may be fairly static. They record a fact that will not change. Or, if it does change there is no need to know what it was in the past.
However, I prefer to error on the side of always asking if we should be retaining the transitional context of data when we go through system design. It's "X" today, but it was "F" yesterday and "T" two weeks before that. Is it helpful today, or may it be helpful in the future to know the prior states of a data element?
If the answer is anything other than an absolute no, then you should record the time and date along with the data value every time it changes. In some cases you may also want to capture a reason for the change.
This is nothing new. Tessitura already does it in many areas. However, there are also areas where it's not captured and I know that many of us wish it was.
Error on the side of always capturing the historical context of the data. Also plan up front to develop purging processes that are time based and can remove data elements in a manner that does not break the historical integrity of what is left. These would be configurable too, of course. :-)
-Dan