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?
| 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?
A couple of thoughts that hopefully won't drag to topic too far off topic.
I'd like to enter another vote to do away with the n1/n2 format of the constituent record. There are too many opportunities for unique processes or unusual constituent relationships that make n1/n2 awkward. Especially when looking at trying to merge duplicate records without losing historical data. One name per record in t_customer is a much cleaner method.
Which brings us to memberships. At the moment, the membership is a property of the constituent. I would love to see this reversed. Meaning that you could attach many customer records to a single membership entity. This is similar in my mind to the earlier posts about creating groups of constituents.
Hear, hear!
But even what a constituent is needs to be thought through. Think about e-mail addresses. A particular constituent, let’s call her Lucie, likes to get e-mails from FGO both at work and at home, at two different e-mail addresses. Currently, we need to create two Lucies in the system. What if both of them buy tickets? Give gifts? Volunteer? So, really, eaddresses need to be semi-independent, perhaps attached via association to a constituent.
Lucie
--------------------------------
Lucie Spieler
IT Development and Training Manager
Editor, Season Program
Florida Grand Opera
8390 NW 25th Street, Miami, FL 33122
Phone: 305-854-1643 x 1521
Fax: 305-856-1042
Ticket Office: 800-741-1010
www.fgo.org
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Levi Sauerbrei Sent: Tuesday, October 20, 2009 11:27 AM To: Lucie Spieler Subject: Re: [Tessitura Next Generation Forum] Relationships, anyone?
From: Beth Varro <bounce-elizabethvarro6946@tessituranetwork.com> Sent: 10/20/2009 10:10:39 AM
Andy's post makes me think of another case: we have complicated relationships in our Education department regarding who is paying for a class, who is the "responsible adult" at the time of the class, and who is the emergency contact. For example, grandma may be buying the class for her grandchild, but the kid's parents are the ones responsible for the child. Or vice versa - the child stays with their grandparents during the summer, so the parents pay for the class and the grandparents pick up and drop off. Who gets recorded as the person who paid for this class? Who should get the confirmation letter? Who should get a letter about class attendance closer to the start date? And the emergency contact could be anybody - and may or may not have a record in Tessitura. * * * * * All aboard to experience a legendary journey on the world’s most famous ship. Titanic: The Artifact Exhibition is now open at the Science Museum of Minnesota. Log on to www.smm.org/titanic today to reserve your boarding pass. Be social! Find the Science Museum on Facebook, Twitter, MySpace and more. Log on to www.smm.org/social for more information. Elizabeth A Varro Membership Manager Science Museum of Minnesota (651) 265-9829 ----- "Andy Jensen" <bounce-andyjensen1844@tessituranetwork.com> wrote: | From: "Andy Jensen" <bounce-andyjensen1844@tessituranetwork.com> | To: bvarro@smm.org | Sent: Monday, October 19, 2009 6:55:49 PM GMT -06:00 US/Canada Central | Subject: RE: [Tessitura Next Generation Forum] Relationships, anyone? | |
| Education / Class Registration example
|
| 1. Divorced parents.
| 2. While there is an "Ex-Spouse" Association, when a divorced parent registers a kid for a class, we process the payment under the paying parent. Sometimes, both parents need to be notified other times not. Often, each parent will pay at different times for the same student. If the student lives at both households, Tessitura can only have one parent's address in a student's record automatically. When confirming / emailing an order, having a "send to additional association?" box would be swell.
| 3. Having a "no e-marketing" for both Primary Email and N2_Email would be great. Other than that, I don't see a need for a difference.
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif | Sent: Friday, October 16, 2009 6:33 PM | To: Andy Jensen | Subject: [Tessitura Next Generation Forum] Relationships, anyone? | |
| 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!
| Spam | Not spam | Forget previous vote |
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!
From: Beth Varro <bounce-elizabethvarro6946@tessituranetwork.com>| Sent: 10/20/2009 10:10:39 AM|
| | 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?
Interesting it is. :-)
Answering your ticketing question.
What if...
The operator enters the callers name and that caller is related to a number of other people in different ways.
The organizational rules have been set up that only some of these relationships are considered "joint" for the purposes of ticket purchases. They might be spousal relationships, child/parent relationships or even seat sharer relationships.
When the operator views history of the ticket purchases they would see the history of all of these related people with indications of their relationship type so that they know where the records came from. Maybe they could also see that there are other relationships that are not being displayed, but by checking them off they can see them.
Backtracking to your other questions...
Clearly there would need to be defaults. The defaults might need to exist a varying levels. For example, how the "value" of the transaction is assigned my default one way for Development, another way for ticket purchases and other ways for other types of transactions.
Your scenario's indicate a need for these defaults and the ability to create flexible processing flows.
-Dan
Thanks for all those who responded earlier - great thought starters!
I am one who would advocate for a redevelopment of the n1/n2 model. I think the new model has to be customizable by the patron - allow them to define the relationships in their household. For example, my wife and I have businesses we both deal with and want to be treated equally. Other times, my children are included and sometimes only she has interest (or only I have interest).
I extract from all the responses to this thread that there is no "one size fits all" model - relationships may or may not include spouses, partners, grandparents, siblings, nannies, etc. and that each may all be involved in various levels of the ticket and contributions. There are also internal membership rules for each of our organizations that allow or disallow participation. Having a model managed by the constituent that allows for all the different scenarios yet still makes it easy for the CSR to search & update seems to me to be the best solution.
From a marketing perspective, having 3 or 4 separate accounts for individuals who reside at the same location could be redundant and expensive.
I had an idea to piggy-back on the thread of people who purchase tickets for other people - sort of a "friend’s network". Here is an example:
John Smith goes online to purchase tickets. He buys 2 tickets for himself and 'reserves' 2 adjacent tickets for Martha Anderson - one of the people in his account on his "Friends Network". Martha (who is a constituent and opted in to John's friend network at some previous time) gets a trigger email that says something like "John Smith purchased 2 tickets for Music Man on December 1, 2009. There are 2 reserved tickets for you. Please go to xxx.com and enter code A1B2C3 to purchase these tickets. They will be released in 24 hours. Please contact John Smith at email address johnsmith@gmail.com if you have any questions." If Martha does not purchase in the 24 hours, the tickets are released and John receives an email. If Martha does purchase, John receives a confirmation email.
Dan, I'm glad you mentioned the idea of transactions having the relationship somehow available to the operator. I agree that appending each transaction, address, phone, email etc. with the relationship and/or other account name would be key, and also being able to do this after the fact if you find the original relationship selected was inaccurate. That coupled maybe with a kind of audit trail within the transactions etc. to advise us of a change in the relationship would probably be needed as well.Using the idea of defaults as well would be a good idea. Maybe having an option to override the default relationship when entering a gift, membership, ticket sale etc. so that you can assign a separate relationship would work well.