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.
Beth,
These questions are begging for a rule based system.
What if in your scenario...
The person paying for the class is recorded as the person paying for the class.
The person attending the class is recorded as the attendee.
The responsible person/emergency contact is recorded as the emergency contact.
The person who has the right to pick up / drop off is so recorded.
Confirmation letters and future informational communications are sent to those related entities who have an appropriate "communication subscription" for this event flagged in their account. In other words each entity can opt in or out of the communication flow.
Also keep in mind that it may be possible for more than one person to be flagged for each of these relationship, and that one person could be flagged for more than one relationship in this scenario.
On the payment side, if more than one person is flagged as "owning" the value of the payment (say both divorced parents), the actual transaction would be recorded as having been made by the person who actually paid.
Using your scenario...
The person who get's recorded as the one who paid for the class is the person who actually pays. However, other persons could get recorded as "owning" the value of that payment. The "confirmation letter" concept might need to be revisited. A transactional receipt should be sent to the person who actually paid. A letter acknowledging "assignment of value" should go to the people who are recorded as "owning" the payment action. The confirmation of registration could go to the attendee, or optionally the registered "responsible" adult(s), or both/all.
The point is that by keeping the transaction and records required as granular as possible they should be able to be linked together in ways that get you what you need.
-Dan
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.