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
Hi,
The ability to build these relationship webs is a functionality we would all like to see. But they do require gathering a lot of information from patrons. When Jane buys the Dance series, does she also fill out the constituent information for Janice? Her work associations? There are practical limits to the amount of good information we want or need to gather in some situations. We have seen it at the Science Museum with selling gift memberships. Most of the generous givers don’t have the detailed information we want on the member, so we either get bad information or need to back-fill, which is time consuming. But we do want to track this association. We will all use this relationship functionality to different levels, and the need to stream-line or “turn-off” its use in some circumstances is also a needed functionality: so ticket sellers and patrons don’t need to wade through a lot of fields unnecessarily, if that business decision is made by the organization.
Ray
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Alan Levine Sent: Tuesday, October 20, 2009 4:48 PM To: rbernard@smm.org Subject: RE: [Tessitura Next Generation Forum] Relationships, anyone?
This e-mail message is intended only for the recipient(s) named above. This message may contain trade secrets, attorney-client communication, or other privileged and confidential information. Any review, re-transmission, dissemination, reproduction or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the Sender and delete the material from any computer.
Spam Not spam Forget previous vote
Chuck,
I think these are some great ideas. But, we have to use some common sense about when we collect this kind of relationship / association information.
In many cases, it depends on the depth of the relationship between our organization and the patron. Alternatively, if there are special requests / privileges that the patron wants to use / allow.
For example:
If the person just walks-up to the box office on the night of the show and buys a ticket. All of this stuff tends to gets in the way of selling the ticket.
If the person buys a single ticket on the web site or through the phone room, you may not get this data in all cases. That is likely OK. Except if, we already have the address on file. We need to make sure that we are not sending out multiple mailers to the same household. At that point we should establish a household relationship between two persons we already have in the database, or remove a duplicate, or inactive another account because someone has moved and we have no forwarding address.
If the purchaser of a subscription wants to allow someone else to make changes to a subscription, or someone else to pick up a subscription, you may want this kind of relationship information. Because the purchaser is requesting that, that this person is granted a pick-up privilege.
If you are going to be caring for a person’s child during an educational situation this kind of information is essential. To know who can do pickups, who needs to know about changes or problems that come up during the course.
Having information about household relationship for donors that have membership privileges is very useful for accurately managing theses relationships. Some organizations sell household memberships.
Having household relationship information allows us to not send duplicate mailers to the same household.
I can see a time in the future if we go down this road. When we are going to have to go through our database of individuals and work on house holding individuals so we are not sending out a large number of duplicate messages and mailers to the same household because we have not gathered relationship data. Particularly from the web site.
Implementing these changes will allow for new flexibility.
This is great.
But it has to be done carefully so it does not get in the way of business flow, or it offend our patrons because we are asking for too much information to keep our system working.
--Tom
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif Sent: Tuesday, October 20, 2009 11:34 PM To: Thomas Brown Subject: Re: [Tessitura Next Generation Forum] RE: Relationships, anyone?
From: Alan Levine <bounce-alanlevine7254@tessituranetwork.com> Sent: 10/20/2009 4:45:41 PM
I love all the ideas in this conversation. I agree that all of the relationship tracking would be wonderful as long as it is made easy enough to customize, turn on and off, allow for consortiums to decide to share relationship information or not, provide operators and the web with easy entry, allow information to be required or not required, etc.
To add to that, it would be great to be able to easily indicate that the patron was asked for the information and declined to provide so that they don't keep getting asked for information that they do not want to provide, as well as have an easy indicator for how the information was received (e.g. provided by patron, newspaper article, from a solicitor, etc.).
This is some serious brainstorming - my head's spinning! A few thoughts:
I still think it's helpful to have accounts that represent family units or households (couples, partners, roommates, whatever) rather than individual accounts for everyone. They tend to make ticket purchases and donations as a unit, and even if one person is usually the driving force behind it, we may have no way of knowing that. Maybe the group relationships that folks have suggested would serve the same purpose. My concern is that the more things are split out, the more chance there is for errors, missing links, duplicate mailings, duplicate records. (And I admit to being one of the aforementioned development people who like to see the whole picture in one place.)
That said, having more individuality for each person in a household record would be really great, and would allow for more personalized service. It would also make it easier for that person to be split into a separate account if a relationship ends or a child becomes an adult.
I'm picturing something akin to the general tab that would contain the default contact information, salutations, etc. for the household (however you define that, or the patron does). Separate tabs for each member of the household, to add unique details/relationships/etc. as you learn them. (There are thousands of patrons whom we do not yet know that well, but it will be handy when we do!) Perhaps separate tabs for box office, development, education, memberships, etc. to track their relationship with the member(s) of the household.
When someone splits off from the household, they should remain linked to the transactions made pre-split. Maybe they could be shaded or marked in some way to note the distinction.
I'm looking forward to seeing how this all develops!
Thank you Sarah for chiming in.
Since I was and still am so genuinely stumped as to the enthusiasm (generally) of the participants (mostly IT) of this thread as to the benefits/necessity of going with a "one person/one record, split everything and layer on the relationships" or some combination thereof approach that I talked to several key people here about it and left my own feelings out of it. Very interesting results.
We agree that all of this is great in theory. It's applying it to the practical realm we struggle with. It is exponentially more work to handle two individuals, and their joint relationship instead of their "account", and this flows like molten lava throughout all business practices.
There is an inherent margin for error built into a system where operators are making decisions that are perhaps 100% based on assumption - even the seemingly straightforward "she signed the check, she decided" doesn't take into account the kitchen table conversation where he persuaded her that the valet parking perk is worth it to him, since he parks the car and hates walking to the show.
We can only do the best we can do, and the system shouldn't reflect assumptions that are in reality, based on nothing at all. A central strength of Tessitura is in ability to transact financial business and then reflect it in a straightforward, "no discernment or special training needed" way. Any relationship "features" needed to be integrated into that strength, compliment it, and not diminish it. Otherwise the credibility of the system comes into play, and no one wants to be distracted by those questions all the time. (Split values got no traction, and reactions verged on incredulous. Don't think we'll be setting our "defaults" to include that aspect of NextGen if it gets that far.)
I understand the value of blue-sky thinking. Fundraising is certainly impacted by relational knowledge. That Jane and Janice were once friends and had a falling out - holy cow, I sometimes can't even keep up with my real friends at that level. It is important to the organization if they can't be seated next to each other, certainly. Is this tracking possible or practical at the scale that we are talking about?
One solution is to create a portal application that our patrons opt into and then maintain themselves (think Facebook for Tessitura), and then we automate the tracking of who "Unfriended" each other?? Unless the heavy lifting was on the patron themselves, how would we Actually Do This? And who? The conference Development track focused numerous times on motivating Development officers to actually use Tessitura to track their cultivation work... with patrons maintaining at least some of their own relational data, we could have some confidence that that portion was at least what the patron wanted us to believe??
Tom's bringing up that we will be looking toward having to create a routine in the future to deal with essentially unconnected "duplicate households" - I couldn't agree with him more. This will be an interesting Tessitura Conference topic to replace that which we "used to" have about "web duplicates" =)
Exciting and invigorating times at Tessitura, that is for sure. Since I don't really understand how much "weight" this forum has in the overall process, I thought I should comment even though some of this is backtracking. Thanks!
Erin
Hi Erin,
Your viewpoints are shared with many in the departments around here who are charged with patron relationship management in one form or another. There is a reason why the technical types such as myself get excited by the models we're talking about. I think it's a worthwhile exercise to try and explain that, so I will.
Before I do though, rest assured that I'm in complete agreement with the concerns you and others have voiced. Regardless of how the system is structured it must be done in a way that is workable for staff and patrons alike.
My enthusiasm for a different model than the one we currently have is based partially on the limitations that our current model imposes. These limitations require that we devise sometimes elaborate workarounds in process and procedure to realize our needs. Those workarounds often end up with results that are undesirable from the point of view of both staff and patrons. I've heard plenty of concerns voiced in the past that we have trouble aligning salutations, addresses, email addresses, constituencies and other attributes with specific patrons within an account.
You mentioned that "the system shouldn't reflect assumptions that are in reality, based on nothing at all". I agree. I would also add that the system shouldn't impose limitations that are in reality, based on nothing at all.
The N1/N2 concept is a good example. There is no way that I can ever have a Name 3. It can't be. The system was designed with this limitation. I feel that a new system should be designed so that I can have Name 1-?. I should be able to decide how many names I want to have per "household" on a case by case basis.
When we discuss creating individual records and then building "relationships" we have to keep in mind the multiple meanings that the word has in this context. On the one hand, we use the term "relationship" to refer to the social interaction between multiple people. On the other hand, we're using the term "relationship" to describe the linking of data elements within an overall data structure.
If I design a data structure and in the process make the decision that there can be 2 names associated with an account, I have in effect limited my ability to ever have more than 2 names. However, if I design the system so I can have any number of names I have realized the goal of not reflecting arbitrary assumptions and/or limitations.
Some of the concerns I've heard expressed really don't have as much to do with the structure of the data as they do with the presentation.
If we create individual entity records for people, we can also create a "household" view that presents them as if they are always inextricably linked. The linkage could be transparent. For all practical purposes we could create a presentation that makes it look just like our current N1/N2 method. Yet, behind the scenes the data would be structured so that the names are pulling from different accounts.
Better yet, your organization could have a view that looks just like our current one with N1/N2 presented on the "household" account form, while another organization displays three names, and yet another organization has a drop down list displaying all names with a particular association or set of associations.
However, if you create a data structure that captures N1 and N2 in the same account, and only N1 and N2 in that account, then you have limited your ability to ever do anything different with regard to the presentation of names for a particular household.
Perhaps we need to attempt to split the discussions of data structure design from presentation.
Chuck?