Relationships, anyone?

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?

Parents
  • 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?

Reply
  • 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?

Children
  • Former Member
    Former Member $organization in reply to Matthew Hodge
    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!