Relationships, anyone?

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.'

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

Hi All,

Good day.

I think to identify a real world item needs three components.

these are time, object and logic.

in the current Tessitura structure, the time component is missing.

So there is an overlap problem in the constituency process.

the association time frame is not the same time frame as constituency.

So we need a tx_ table to synchronize them.

have fun

Ben

 

Hello, all,

Lots of great perspectives here. Some of what I was thinking of has already been said. So I guess I'd boil my suggestion down to this - Have separate entity/record types for "people", "households/company/org" (and grouping of people), and "benefits." (Maybe other types?)

"People" entities would have certain, personal pieces of information like name, birth date, e-mail address, phone numbers, etc.

"Household" entities would have information like an address, mailing restrictions, etc.

"Benefit" entities would contain information related to a membership/donation/etc.

Any number of people could be associated to a household/company, using different types of associations. Both individual people or a whole household could be associated with a benefit.

Rules that are set within each benefit would determine which types of associations those benefits are allowed to disseminate down to (and in which direction). There could be simple rules like: parent->child, yes; child->parent, no. Or more complex ones like if a member of a household has made a donation, do the benefits that go along with that apply to whole household, or only certain types of relationships within the household, or only certain types of relationships regardless of if they're in the same household or not. Another example, for a company that has been given an admission discount for its employees, it would be something like: company->employee, yes; employee->company, no.

This would do away with the N1/N2 requirement and allow for much more flexibility in benefit structures. While at the same time, the rulesets would allow for the enforcement of a N1/N2-type structure if it's desired.

   -Morgan

Ooops... "(and grouping of people)" should have read "(any grouping of people)".

   -Morgan

Hi Morgan,

Good day.

You can use "More ---> Edit" to modify your post.

have fun

Ben

Hi everyone,

While going through a period of extensive data cleaning we made the decision to move to one record per household, but this isn't always ideal for many reasons: you can't attribute all of the data to one person or the other, flexible communication options are limited and you are restrained by the N1/N2 set up when there could potentially be more primary customers at that same address. However, now in the midst of custom work on the education side, we are moving back towards one record per individual in order to make parent/child associations and such work. In short, neither scenario is ideal and I agree with Ken that whatever comes up in the Next Generation process, it needs to be really intuative and able to handle any of the potential situations we could all face!

Katie.

Hi everyone,

Thanks again for a great conversation about constituent relationships.  To close one part of the loop, presented here is a Constituent Model document that was developed as a result of your feedback here, feedback from the Chicago Summit, and a series of conversations and revisions with the Member Advisory Committee (MAC).  The MAC, in particular, likes what we've come up with as a starting point for constituent relationship work.

We are using this document as our rough guide as we begin developing Release One stories surrounding constituents and constituent relationships.  As we begin work with the Epic Story Committee, we will no doubt continue to revise and refine, but wanted to be sure that the working draft we have is distributed and available to the Tessitura Community.

As always, we invite your comments, as this process continues to evolve.

Andrew

  (P.S. If you have trouble with the link, you can also view it from the Next Gen/Additional Materials page - the document is called Constituent Model).

I had a further question about relationships that I wanted to ask.

In my previous life at Musica Viva, I was working selling corporate sponsorship and before we had Tessitura, I was taking advantage of a not-for-profit licence of Salesforce.com (an online CRM, for those who haven't heard of it). One thing SF.com does very well is that they have three types of records for corporate / organisation contacts.

They have one record type for the organisations, another record type for all the contacts, and then a third record type that represents sales opportunities. (This would be the equivalent of a solicitation in Tessi.)

What's clever about it is that you can track the sales process (which often can involve multiple people from the one company) on the "opportunities" record and it will automatically update the contact and the company record.

So, for instance, if as part of my sales process, I send a proposal to Person A at Company X, it will note that action on the opportunity record (which might be "$50K Sponsorship from Company X"), it will then note that action on the Company X record and on the Person A record. This means that later on, if I ever want to look at my historical records, I have the choice of following up all my dealings with a particular person (very convenient if one person moves around from company to company, or they're on my schmooze list for a concert).

But, by the same token, I can also look at all the dealings I've had with the company on the company record (great when we're about to make a new approach).

Finally, if I want to know how things went on that particular sale, I can just look up the opportunity record.

This three way arrangement - an opportunity which links back to the contact and the company is very effect, and I was wondering if - while all this discussion is going on about relationships - whether there was some plans to implement something like this, which might help those Development folks going after complex sales involving multiple decision makers in large organisations / departments?

This is a great idea. To be able to trace ALL sponsorship interactions on
both an individual and a company record would be fantastic.




From:"Matthew Hodge"
To:rebecca.cuschieri@opera-australia.org.au
Date:02/02/2010 05:27 PM
Subject:Re: [Tessitura Next Generation Forum] Relationships, anyone?
Sent by:"Tessitura Next Generation Forum"




I had a further question about relationships that I wanted to ask.


In my previous life at Musica Viva, I was working selling corporate
sponsorship and before we had Tessitura, I was taking advantage of a
not-for-profit licence of Salesforce.com (an online CRM, for those who
haven't heard of it). One thing SF.com does very well is that they have
three types of records for corporate / organisation contacts.


They have one record type for the organisations, another record type for
all the contacts, and then a third record type that represents sales
opportunities. (This would be the equivalent of a solicitation in Tessi.)


What's clever about it is that you can track the sales process (which often
can involve multiple people from the one company) on the "opportunities"
record and it will automatically update the contact and the company record.


So, for instance, if as part of my sales process, I send a proposal to
Person A at Company X, it will note that action on the opportunity record
(which might be "$50K Sponsorship from Company X"), it will then note that
action on the Company X record and on the Person A record. This means that
later on, if I ever want to look at my historical records, I have the
choice of following up all my dealings with a particular person (very
convenient if one person moves around from company to company, or they're
on my schmooze list for a concert).


But, by the same token, I can also look at all the dealings I've had with
the company on the company record (great when we're about to make a new
approach).


Finally, if I want to know how things went on that particular sale, I can
just look up the opportunity record.


This three way arrangement - an opportunity which links back to the contact
and the company is very effect, and I was wondering if - while all this
discussion is going on about relationships - whether there was some plans
to implement something like this, which might help those Development folks
going after complex sales involving multiple decision makers in large
organisations / departments?


From: Andrew Recinos
Sent: 1/29/2010 1:51:09 PM


Hi everyone,


Thanks again for a great conversation about constituent relationships. To
close one part of the loop, presented here is a Constituent Model document
that was developed as a result of your feedback here, feedback from the
Chicago Summit, and a series of conversations and revisions with the Member
Advisory Committee (MAC). The MAC, in particular, likes what we've come up
with as a starting point for constituent relationship work.


We are using this document as our rough guide as we begin developing
Release One stories surrounding constituents and constituent relationships.
As we begin work with the Epic Story Committee, we will no doubt continue
to revise and refine, but wanted to be sure that the working draft we have
is distributed and available to the Tessitura Community.


As always, we invite your comments, as this process continues to evolve.


Andrew


(P.S. If you have trouble with the link, you can also view it from the
Next Gen/Additional Materials page - the document is called Constituent
Model).





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!

I have a question regarding ticketing functionality and relationships/associations.

Does this scenario currently exist in Tessitura or am I just having a spurt of wishful thinking?

Ms. Smith and her longtime friend Ms. Jones have been subscribers for forever, before Tessitura was born.  They ALWAYS sit together, but they always buy season packages individually.

This worked out great when we were in the same house and same seating configuration for the past 50 years, we did a simple season renewal rollover and the ladies were automatically sat together.

But, and here's the rub - we recently moved into a new flexible venue where a rollover is not possible because of the different configurations and our use of Super Packages.

If a new employee (or me before my morning coffee) sits Ms. Jones in seat A1, but I forget about Ms. Smith then seat A2 may go to someone completely different.

Is there a way when doing seating like this, manually by hand, that the Association tab can somehow automatically remind me that "Hey you put Ms. Jones in seat A1, so you better put Ms. Smith in seat A2 because they are linked as friends and they attend the same performance"?

If not, which I'm guessing there's not, how could I utilize the Associations already in each patron record to help me not have a problem like this?

We recently had an issue where this came up. 

We had a show set up as General Admission for our Studio Theatre (98 seats).  While Ms. Jones and Ms. Smith were on the same performance night it wasnt an issue to seat them together in the GA house because there were no reserved seats.  However, we restructured the house from GA to Reserved Seating - same number of seats just actual seats now. 

So we (me and the help of the wonderful staffers in the consortium) resat everyone from the GA house into the Reserved house.  While I might have known about Ms. Jones & Smith's association, the staffers helping did not so Ms. Jones might have been put in A1 while Ms. Smith, still on the same night, was put into E 12.  Would there have a been a way that we could have utilized Associations in this instance? To be honest the decision to restructure came 2 weeks before the first performance, so time was of the essence and this issue was not on my radar until we sent out the tickets and I started having to reseat groups together.

Thanks

I have a question regarding ticketing functionality and relationships/associations.

Does this scenario currently exist in Tessitura or am I just having a spurt of wishful thinking?

Ms. Smith and her longtime friend Ms. Jones have been subscribers for forever, before Tessitura was born.  They ALWAYS sit together, but they always buy season packages individually.

This worked out great when we were in the same house and same seating configuration for the past 50 years, we did a simple season renewal rollover and the ladies were automatically sat together.

But, and here's the rub - we recently moved into a new flexible venue where a rollover is not possible because of the different configurations and our use of Super Packages.

If a new employee (or me before my morning coffee) sits Ms. Jones in seat A1, but I forget about Ms. Smith then seat A2 may go to someone completely different.

Is there a way when doing seating like this, manually by hand, that the Association tab can somehow automatically remind me that "Hey you put Ms. Jones in seat A1, so you better put Ms. Smith in seat A2 because they are linked as friends and they attend the same performance"?

If not, which I'm guessing there's not, how could I utilize the Associations already in each patron record to help me not have a problem like this?

We recently had an issue where this came up. 

We had a show set up as General Admission for our Studio Theatre (98 seats).  While Ms. Jones and Ms. Smith were on the same performance night it wasnt an issue to seat them together in the GA house because there were no reserved seats.  However, we restructured the house from GA to Reserved Seating - same number of seats just actual seats now. 

So we (me and the help of the wonderful staffers in the consortium) resat everyone from the GA house into the Reserved house.  While I might have known about Ms. Jones & Smith's association, the staffers helping did not so Ms. Jones might have been put in A1 while Ms. Smith, still on the same night, was put into E 12.  Would there have a been a way that we could have utilized Associations in this instance? To be honest the decision to restructure came 2 weeks before the first performance, so time was of the essence and this issue was not on my radar until we sent out the tickets and I started having to reseat groups together.

Thanks

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?

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!