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!
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?
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?
From: Alan Levine <bounce-alanlevine7254@tessituranetwork.com> Sent: 10/20/2009 4:45:41 PM
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.
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?
-Dan
Applying it to the practical realm would indeed be a challenge and there would need to be some heavy consideration as to scaling and how involved the end user and the patron would need to be. As mentioned the more granular you get the more room for error and the more intrusive it would be to our constituents.Also the more this concept is talked about the more it seems like it would affect every aspect of the constituent if adopted. I can't really think of any part at least of the constituent record that would not potentially be shared with another constituent record. I don't however think that is necessarily a bad thing it's just a rather intense idea.
Wow Dan, that is an interesting idea.
"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."
I’m glad this discussion about the practicalities of using the system is happening. I was working on how to phrase my 2 cents. While I get really excited about a data model that actually reflects the real-life situations of our patrons, as I was monitoring the discussion, I became more and more concerned about the resource requirements of maintaining a system that is so flexible and captures so many different permutations of the data. Erin’s points about who is going to enter this information and maintain it are all very good questions. We need to be very careful about making the burden imposed by the Next Generation outweigh the benefits of the next generation – or another way of putting it, what do we really need for our businesses to run better (rather than trying to index all of real life)?
While the suggestions about making these features scalable and enabling them to be “turned off” begin to address this issue, they actually increase the burden on the DBA/IT staff to build consensus about how the organization wants to do things, and then implement the needed configuration. I can’t tell you how many times during our conversion my staff have asked me “Why doesn’t Tessitura just do it that way? Isn’t that the way the business works?” My answer, of course, is “Tessitura CAN do it that way, we just have to set it up.” But it’s a valid point – we have to balance customizability with simplicity and “straight-forwardness” if we want to help the vast majority of the industry that can’t invest a lot of money in thorough database management.
So, getting back to the discussion at hand, I love the idea of having some kind of unique “record” in the system for every individual, and various options for webbing these individuals into relationships with each other, but I’m particularly concerned about carefully deciding where the “account” function falls (by which I mean the record to which transactions, gifts, orders, tickets, solicitations, etc. are attached) – at the “relationship” level, at the “individual” level, at the “household” level?
One thing I know is that I do not want to have my users having to select all the individuals in a household to which a contribution pertains every single time they’re entering a contribution. There needs to be some “account” structure that is a little more stable that unifies this information. Dan’s point about enabling this “account” structure to have more than 2 names on it is right, and, I think, a necessary improvement with Next Gen.
By the way, after writing all that, I’m wondering if we should award points on this forum for brevity…J
Kirk Mortensen Database Administrator
tel: 650-463-7122 fax: 650-463-1963 kirk@theatreworks.org
“SPELLBINDING… PURE MAGIC” - Chicago Sun Times
THE CHOSEN by Aaron Posner and Chaim Potok October 7 - November 1 Mountain View Center for the Performing Arts
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Ryan Rowell Sent: Wednesday, October 21, 2009 12:27 PM To: Kirk Mortensen Subject: Re: [Tessitura Next Generation Forum] RE: RE: Relationships, anyone?
Applying it to the practical realm would indeed be a challenge and there would need to be some heavy consideration as to scaling and how involved the end user and the patron would need to be. As mentioned the more granular you get the more room for error and the more intrusive it would be to our constituents. Also the more this concept is talked about the more it seems like it would affect every aspect of the constituent if adopted. I can't really think of any part at least of the constituent record that would not potentially be shared with another constituent record. I don't however think that is necessarily a bad thing it's just a rather intense idea.
From: Erin Koppel <bounce-erinkoppel9175@tessituranetwork.com> Sent: 10/21/2009 1:24:24 PM
I've just read your post Dan, and quickly because I'm headed into another meeting. Please don't misunderstand my point. I *want* another model. I absolutely get that N1/N2 is limiting for all the excellent reasons spelled out in this post and others and I was not championing the existing N1/N2 model. The essential point that I mean to make is that whatever structure is decided upon can't risk imploding under it's own weight for the vast complexity that is built in. I know my car turns on when I turn the key, and that the steering wheel is the tool by which I navigate the streets. Vastly more complicated things are going on under the hood - I get it. BUT, if the driver of the car is too concerned about ancillary items which demand attention - a crying child, a cell phone ringing, the coffee which just spilled in their lap, the weird knocking noise coming from the fender - the less focus is on the road. And then, all the sudden, you look up and you are not where you intended to be, or you just ran a red light, or worse. What I want to ensure is that the Tessitura "car" will take us all to where we want to be. This is a weird post for me! Can you tell I have a lot of crying children in my car?!?! I will go back and look at everyone else's comments again and I reserve the right to modify my comments =)
I've just read your post Dan, and quickly because I'm headed into another meeting. Please don't misunderstand my point. I *want* another model. I absolutely get that N1/N2 is limiting for all the excellent reasons spelled out in this post and others and I was not championing the existing N1/N2 model.
The essential point that I mean to make is that whatever structure is decided upon can't risk imploding under it's own weight for the vast complexity that is built in. I know my car turns on when I turn the key, and that the steering wheel is the tool by which I navigate the streets. Vastly more complicated things are going on under the hood - I get it. BUT, if the driver of the car is too concerned about ancillary items which demand attention - a crying child, a cell phone ringing, the coffee which just spilled in their lap, the weird knocking noise coming from the fender - the less focus is on the road. And then, all the sudden, you look up and you are not where you intended to be, or you just ran a red light, or worse. What I want to ensure is that the Tessitura "car" will take us all to where we want to be.
This is a weird post for me! Can you tell I have a lot of crying children in my car?!?! I will go back and look at everyone else's comments again and I reserve the right to modify my comments =)
I agree with Erin that while we need a new structure we need to make sure it is not so complex as to be unusable. On the other hand, at this stage of development, I think we need to think wide and wild.
At some point, yes we need to be practical, but in my opinion, if we are too practical this early we limit our imagination.
Its like my career counselor told me, don't think about what you can do, when trying to figure out what you want to do.Dale
Hey Erin,
I sort of figured we were saying similar things in different ways from different points of view.
I agree 100% with your analogy - having too many distractions in the car can lead to bad things happening.
However, that has nothing to do with the fact that there are vastly more complicated things going on under the hood that allow your car to do what it does. If a driver allows a distracted situation to occur, is it the responsibility of the car designer?
On the other hand, I have encountered technical and/or mechanical things in my life that simply did not work as intended. Often because they were just to darned complicated. The complexity of the technology or machinery got in the way of the consumer being able to effectively use it.
I once had an early 1970's car that I loved. It was ugly. It would never impress my friends. But, it would take me where ever I wanted to go, and with a standard set of tools and a few extra parts tucked in the trunk I could get up and running again without a costly expenditure of time and money.
I suspect that is what you're driving at. (pun intended?)
Sure - let's get the most flexible design possible. Even if that means that the mechanics under the hood are so complex that the everyday user will never understand them. All that is fine.
Unless the car doesn't run reliably. And if it doesn't run reliably, don't expect the user to be able to help because if the car is so complex that only specialists can understand it.
Point taken - and I would suspect, universally agreed to.
Thanks Kirk! If we award points for brevity I'll lose for sure!
Your right of course. To ease initial configuration we'll need to group logical sets of options with predefined values. Then allow the folks doing system configuration to load them and tweak them from there. A lot of attention will have to go into the implementation process.
Do I get brevity points? :-)
Unknown said: Your right of course. To ease initial configuration we'll need to group logical sets of options with predefined values. Then allow the folks doing system configuration to load them and tweak them from there. A lot of attention will have to go into the implementation process. Do I get brevity points? :-)
Points awarded! ;-)
And I agree with this. As long as we can set some defaults around how we treat each relationship that will keep things simple for the front end. I would also say that it needs to be easy to override those defaults if necessary because, at least here at the museum, the only rule seems to be 'there are no rules.'
Great! So long as we’re all in agreement about keeping it both user-friendly and admin-friendly (i.e. not too much extra work for the DBA to “set things up”), I’m all for a data structure that has one record per individual.
An interesting model I saw once in a fundraising DB (can’t remember which one it was), treated families and households as just another kind of organizational record. So, you have your org record for XX Foundation with several individuals (employees, board members, assigned solicitors) associated; and you have your org record for the Smith Family with several individuals (Mom, Dad, little Jimmy, Grandma, Foster Kid, Dad #2, etc.) associated. The addresses, financial transactions, etc. would be kept on the org record level, but personal contact info (like cell phones) could easily be entered at the individual level. (That gives me a little idea – in this situation it would be great if Jimmy’s cell phone could be seen on the “general” tab of the Smith Family record, but there would be a column clarifying who’s cell phone it is.)
It seems to me this model could satisfy a lot of the needs we’re talking about… but I’m sure I’m missing something…
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Kjersten Schladetzky Sent: Thursday, October 22, 2009 8:47 AM To: Kirk Mortensen Subject: Re: [Tessitura Next Generation Forum] RE: RE: RE: Relationships, anyone?
Dan Spees: Your right of course. To ease initial configuration we'll need to group logical sets of options with predefined values. Then allow the folks doing system configuration to load them and tweak them from there. A lot of attention will have to go into the implementation process. Do I get brevity points? :-)
Dan Spees:
From: Dan Spees <bounce-danielspees8805@tessituranetwork.com> Sent: 10/22/2009 10:05:03
Hi All,
A late addition to this blog. This whole relationship thing has been something our Development department has been struggling with for a while. Like Ken, at Sydney, we have complex relationships between our major donors. Someone may be a Director/Board Member with several companies who all have a relationship with the ROH and to each other. Each organisation also has several employees of all types at different addresses, who each have a professional and, possibly, a personal relationship with the ROH. Making a graphic of the cross relationships is like drawing a spider web!!
I, like Kirk, have also seen models where all these relationships are possible, but there is a danger of allowing things to get too infinitely configurable.
I’ll keep tabs on this blog now and see what comes out in the wash.
Debbie