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?
And some random thoughts from me.
After a lot of soul-searching , we decided that we didn’t ever want two records for the same person or org, and we didn’t ever want two people/orgs sharing the same record. One person/org = one record, and do everything else with associations in some way – that’s nirvana. We haven’t reached nirvana yet, although Kim has just switched off the Org Contact constituent type, which is a major stepping stone along the Way.
You can sort of cope that way using Associations now, but that causes some stress, particularly for Dev persons, who really like to see relationships right there on screen, and leads into very messy ways of trying to associate particular addresses via particular types of association……
So we’re clearly in the “No more N2” camp, though after some full and frank exchanges of views in Chicago , I realise that not everyone agrees, and we certainly need a way to group particular significant sets of constituents together (like households or spice or companies or families or co-members), probably also with a way of marking some of them as subordinate within that set (eg special flags/ types of record for dependent children vs parents in a household set, so we can know not to address the rugrats directly.), and with a way to address the set rather than the individual constituent in some circumstances and not in others.
Really what we need is a way of associating and grouping individual constituents that is so flexible, generic, and intuitive, that it can deal, not only with every way that we currently need to build associations between people/orgs, as Chuck is asking us for, but also with every tricky new way that we’re going to think of as soon as we see what we can do with the new version, but that we haven’t thought of yet. And present the relationships in such a way that the Dev person knows exactly what’s going on, but the ticketing person doesn’t say ”..and how did you enjoy The Blue Room, Mrs Smith?”, when Mr Smith actually went with Someone Else.
Now that sounds do-able. Easy enough, Chuck?
Ken
Ken McSwain Business solutions Manager
kmcswain@sydneyoperahouse.com
T+61 2 9250 7876 F+61 2 9251 7821 M 0418 659 360
SYDNEY OPERA HOUSE BENNELONG POINT
GPO BOX 4274, SYDNEY NSW 2001, AUSTRALIA
SYDNEYOPERAHOUSE.COM
Please consider the environment before printing this email. =====This message is intended for the addressee(s) named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this email are those of the individual sender and are not necessarily the views of the Sydney Opera House Trust=====