Primary Addresses

Chuck and all

Just some thoughts from me (as someone partly responsible for managing access to data in a consortium environment):

1.     There is definitely a need to create a constituent on the very smallest amount of information (we have run hugely successful promotional campaigns where just a name & email address is collected). So, I think constituents should be able to be added without a postal address (we often ‘bodge’ a postal address to deal with this requirement currently). Then, over time a fuller record may or may not evolve. In this context, I would prefer as an end user that if there is no postal address that I have access to then that constituent should be automatically left out of any postal address list that I build (in whatever context) – are we talking a ‘No Postal Address’ (and similarly ‘No Email Address’) flag or something?

2.     On the basis that there is ‘No Postal Address’ on a constituent’s record then it would be better that I should not be allowed as a ticket seller (or as the customer buying online) to elect a mail delivery method if the postal address criteria is not met. We don’t yet offer ‘Print At Home’ but I agree that we may be facing a time in the future when many more of the tickets we issue are electronic anyway so a postal address will become more and more irrelevant to the way we do business.

3.     I think the interaction between Primary, Address Type and Address Purpose offers too many layers of offering up an address in a mailing context. A discussion with our development team prior to the next gen workshops revealed that they might prefer to set (at a user group level) their own hierarchy of (current terminology) Address Types that the address searching mechanism would search through in order of priority wherever a postal address was being sought (List Manager, Extractions, standard and custom reporting). (I can’t quite picture how that would work...).

There is another point I’d like to make relating to reducing duplicates. One could entertain a scenario where when a user enters a particular address / email / phone no into a constituent record in Tessitura and it does a bit of live matching against data that I DO AND DON’T HAVE ACCESS TO (per my user group rights). Given that the user now has been given the data, it seems to me appropriate for it to match in the background to the constituent database and suggest a list of possible matches for me to choose from there and then (not necessarily revealing any data in that matching process that I’m not already typing in):

e.g. I enter 02 9250 7625 and the system matches to a number it finds elsewhere allowing me to define instantly whether it’s the same constituent or (if the phone number is a switchboard for a company) alerts me to the fact that I might want to make this constituent a member of a group relating to that company.

I would like to see only one instance of an address, email address or phone number on the system to which multiple parties gain access over time (by attempting to put it in themselves subsequently). Our database is riddled with multiple duplicate addresses all of which are exactly the same but which have been entered in by different members of the same organization in some cases or different organisations in the consortium. However, there will be some nervousness that a user from Org A will change the address subsequently and mailouts from Org B will end up at the wrong address because they operate with different business rules. This might make this out of the question.

Just some thoughts!

David

David Joyce Tessitura Business Analyst

djoyce@sydneyoperahouse.com

T+61 2 9250 7625  F+61 2 9251 7821  M 0423 780 014

SYDNEY OPERA HOUSE BENNELONG POINT

GPO BOX 4274, SYDNEY NSW 2001, AUSTRALIA

SYDNEYOPERAHOUSE.COM

One of our assumptions has been around the idea that a Next Generation constituent needn't necessarily have a postal address.  As many of you know this requirement in the current software has caused us to jump through some hoops with web registrations where we actually temporarily create constituents with a dummy address.  So the thought was if a large percentage of your constituents only address you electronically, why bother with a required postal address?  Furthermore, considering the type of "groups with members" constituent model that we've been talking about, why should a every child in a family need an address when all of the children belong to a family that has a postal address?

So yesterday we got into having a big discussion about whether we needed to carry on the notion of a "primary address" for a constituent.  Currently each constituent must have a primary address and that primary address must not be control grouped--everyone can see it. 

Primary addresses has some nice advantages--if you want to analyze purchasing by postal code sometimes you just need any easy way to get to a postal code.  Plus if you've got several addresses on a constituent and none of them really match the criteria for a particular mailing, you've always got the primary address to fall back on.

Obviously if no postal address is required then you can't force a primary address.  You could make a rule like "if there are any addresses, then one of them must be primary".    But then we thought, "does this work in a consortium setting"?  Let's say the Symphony and the Ballet share a system.  Couldn't you make the case that the Symphony might want to store a private address that only the Symphony could see?  And that's the only address the constituent has on file?  You can't say it's the primary address because the Ballet can't see it. 

So several questions:

1.  What about this notion of a constituent with no postal address?  Does that make sense?  Or does the current model feel better?  Even with the group/member model we could say that each constituent has to have a primary address, even if that address is not specifically tied to that constituent.  That's the example of the child's primary address actually being the family's address.

2.  If there were no requirement for a postal address, then there are obviously still times when one is required.  We couldn't have a delivery method of "Mail" if the constituent didn't have an address.  Of course we could require that an order have a shipping address before allowing that delivery method.  But what does this do to subscribers if some percentage of subscribers didn't have postal addresses?  Or is this just the way the world is going and we have to learn to operate that way?

3.  If we don't require an address, what about a primary flag?  Is it ok for a constituent to have say 3 addresses (some shared, some not) and none of them being a primary address?  Is it ok for a constituent to have 3 addresses, all only visible for some part of a consortium?

Believe me it's a nice feeling knowing that we can put questions like this in front a large, interested audience.  We're eagerly awaiting your help.

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!

Chuck and all

Just some thoughts from me (as someone partly responsible for managing access to data in a consortium environment):

1.     There is definitely a need to create a constituent on the very smallest amount of information (we have run hugely successful promotional campaigns where just a name & email address is collected). So, I think constituents should be able to be added without a postal address (we often ‘bodge’ a postal address to deal with this requirement currently). Then, over time a fuller record may or may not evolve. In this context, I would prefer as an end user that if there is no postal address that I have access to then that constituent should be automatically left out of any postal address list that I build (in whatever context) – are we talking a ‘No Postal Address’ (and similarly ‘No Email Address’) flag or something?

2.     On the basis that there is ‘No Postal Address’ on a constituent’s record then it would be better that I should not be allowed as a ticket seller (or as the customer buying online) to elect a mail delivery method if the postal address criteria is not met. We don’t yet offer ‘Print At Home’ but I agree that we may be facing a time in the future when many more of the tickets we issue are electronic anyway so a postal address will become more and more irrelevant to the way we do business.

3.     I think the interaction between Primary, Address Type and Address Purpose offers too many layers of offering up an address in a mailing context. A discussion with our development team prior to the next gen workshops revealed that they might prefer to set (at a user group level) their own hierarchy of (current terminology) Address Types that the address searching mechanism would search through in order of priority wherever a postal address was being sought (List Manager, Extractions, standard and custom reporting). (I can’t quite picture how that would work...).

There is another point I’d like to make relating to reducing duplicates. One could entertain a scenario where when a user enters a particular address / email / phone no into a constituent record in Tessitura and it does a bit of live matching against data that I DO AND DON’T HAVE ACCESS TO (per my user group rights). Given that the user now has been given the data, it seems to me appropriate for it to match in the background to the constituent database and suggest a list of possible matches for me to choose from there and then (not necessarily revealing any data in that matching process that I’m not already typing in):

e.g. I enter 02 9250 7625 and the system matches to a number it finds elsewhere allowing me to define instantly whether it’s the same constituent or (if the phone number is a switchboard for a company) alerts me to the fact that I might want to make this constituent a member of a group relating to that company.

I would like to see only one instance of an address, email address or phone number on the system to which multiple parties gain access over time (by attempting to put it in themselves subsequently). Our database is riddled with multiple duplicate addresses all of which are exactly the same but which have been entered in by different members of the same organization in some cases or different organisations in the consortium. However, there will be some nervousness that a user from Org A will change the address subsequently and mailouts from Org B will end up at the wrong address because they operate with different business rules. This might make this out of the question.

Just some thoughts!

David

David Joyce Tessitura Business Analyst

djoyce@sydneyoperahouse.com

T+61 2 9250 7625  F+61 2 9251 7821  M 0423 780 014

SYDNEY OPERA HOUSE BENNELONG POINT

GPO BOX 4274, SYDNEY NSW 2001, AUSTRALIA

SYDNEYOPERAHOUSE.COM

One of our assumptions has been around the idea that a Next Generation constituent needn't necessarily have a postal address.  As many of you know this requirement in the current software has caused us to jump through some hoops with web registrations where we actually temporarily create constituents with a dummy address.  So the thought was if a large percentage of your constituents only address you electronically, why bother with a required postal address?  Furthermore, considering the type of "groups with members" constituent model that we've been talking about, why should a every child in a family need an address when all of the children belong to a family that has a postal address?

So yesterday we got into having a big discussion about whether we needed to carry on the notion of a "primary address" for a constituent.  Currently each constituent must have a primary address and that primary address must not be control grouped--everyone can see it. 

Primary addresses has some nice advantages--if you want to analyze purchasing by postal code sometimes you just need any easy way to get to a postal code.  Plus if you've got several addresses on a constituent and none of them really match the criteria for a particular mailing, you've always got the primary address to fall back on.

Obviously if no postal address is required then you can't force a primary address.  You could make a rule like "if there are any addresses, then one of them must be primary".    But then we thought, "does this work in a consortium setting"?  Let's say the Symphony and the Ballet share a system.  Couldn't you make the case that the Symphony might want to store a private address that only the Symphony could see?  And that's the only address the constituent has on file?  You can't say it's the primary address because the Ballet can't see it. 

So several questions:

1.  What about this notion of a constituent with no postal address?  Does that make sense?  Or does the current model feel better?  Even with the group/member model we could say that each constituent has to have a primary address, even if that address is not specifically tied to that constituent.  That's the example of the child's primary address actually being the family's address.

2.  If there were no requirement for a postal address, then there are obviously still times when one is required.  We couldn't have a delivery method of "Mail" if the constituent didn't have an address.  Of course we could require that an order have a shipping address before allowing that delivery method.  But what does this do to subscribers if some percentage of subscribers didn't have postal addresses?  Or is this just the way the world is going and we have to learn to operate that way?

3.  If we don't require an address, what about a primary flag?  Is it ok for a constituent to have say 3 addresses (some shared, some not) and none of them being a primary address?  Is it ok for a constituent to have 3 addresses, all only visible for some part of a consortium?

Believe me it's a nice feeling knowing that we can put questions like this in front a large, interested audience.  We're eagerly awaiting your help.

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!

Good thoughts, David (and everyone on this thread!).

Looking at your final thought here regarding duplication of addresses for each consortium member, what happens when one organization wishes to edit the address?  Does it create a new duplicate or does the shared address change for all organizations?

In my experience, the duplication of addresses for each organization has always been done so that each had control over the content (IE, org A could use  “1001 First Street” and org B could use “1001 1^st St” without issue).

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=====

Hi Ryan

From a data management point of view (where I sit) one instance of any given address would be most desirable. From a business perspective there have always been various hurdles (like the one you suggest). However…in a perfect world…(and apologies for the stream of consciousness)

Imagine there is address checking software (e.g. QAS) to at least ensure that if people are trying to enter 1001 1st Street the address can only be entered (or corrected so as to be entered) consistently whoever is doing the typing. This assumes we all accept that there is only one way to enter an address (and conveniently ignores the ‘vanity suburb’ syndrome). This should protect all parties from having ‘their’ addresses materially changed by another user and cut down dramatically on duplicates caused by inconsistent data entry.

If a constituent has moved…user goes into existing address, changes it (enters reason for changing it) and this effectively creates a new address in the database (which is dupe-checked against existing addresses as it is saved). All ‘access permissions’ from the old address carry across to the new address. Users are alerted* when one of their addresses is changed in this way and can elect to stay with the old address (because they have secret information that says the person hasn’t in fact moved) or they can move their ‘pointers’ over to the new address and agree (somehow through the system) to the inactivation of an old address. When no one is pointing at the old address any more it can be genuinely deactivated automatically and never rear its ugly head again.

If there has been inaccurate data entry (e.g. wrong door number) exactly the same happens but the reason type is something like ‘Inaccurate data entry’. Again, owner users are alerted and they can make their own decisions about whether they accept or challenge the change.

* - the alerts may only be apparent when someone is interacting with the record itself, or addresses that turn up in mailout outputs have asterisks next to them to alert the user to the fact that the address may have been superseded, or they can be sent in batch to some poor departmental user with too much time on their hands to approve.

Very specific I know, but hopefully food for thought about another way of looking at the problem.

I think it might be easier to write this email than actually program this…

Regards

David

Good thoughts, David (and everyone on this thread!).

Looking at your final thought here regarding duplication of addresses for each consortium member, what happens when one organization wishes to edit the address?  Does it create a new duplicate or does the shared address change for all organizations?

In my experience, the duplication of addresses for each organization has always been done so that each had control over the content (IE, org A could use  “1001 First Street” and org B could use “1001 1^st St” without issue).

Chuck and all

Just some thoughts from me (as someone partly responsible for managing access to data in a consortium environment):

1.     There is definitely a need to create a constituent on the very smallest amount of information (we have run hugely successful promotional campaigns where just a name & email address is collected). So, I think constituents should be able to be added without a postal address (we often ‘bodge’ a postal address to deal with this requirement currently). Then, over time a fuller record may or may not evolve. In this context, I would prefer as an end user that if there is no postal address that I have access to then that constituent should be automatically left out of any postal address list that I build (in whatever context) – are we talking a ‘No Postal Address’ (and similarly ‘No Email Address’) flag or something?

2.     On the basis that there is ‘No Postal Address’ on a constituent’s record then it would be better that I should not be allowed as a ticket seller (or as the customer buying online) to elect a mail delivery method if the postal address criteria is not met. We don’t yet offer ‘Print At Home’ but I agree that we may be facing a time in the future when many more of the tickets we issue are electronic anyway so a postal address will become more and more irrelevant to the way we do business.

3.     I think the interaction between Primary, Address Type and Address Purpose offers too many layers of offering up an address in a mailing context. A discussion with our development team prior to the next gen workshops revealed that they might prefer to set (at a user group level) their own hierarchy of (current terminology) Address Types that the address searching mechanism would search through in order of priority wherever a postal address was being sought (List Manager, Extractions, standard and custom reporting). (I can’t quite picture how that would work...).

There is another point I’d like to make relating to reducing duplicates. One could entertain a scenario where when a user enters a particular address / email / phone no into a constituent record in Tessitura and it does a bit of live matching against data that I DO AND DON’T HAVE ACCESS TO (per my user group rights). Given that the user now has been given the data, it seems to me appropriate for it to match in the background to the constituent database and suggest a list of possible matches for me to choose from there and then (not necessarily revealing any data in that matching process that I’m not already typing in):

e.g. I enter 02 9250 7625 and the system matches to a number it finds elsewhere allowing me to define instantly whether it’s the same constituent or (if the phone number is a switchboard for a company) alerts me to the fact that I might want to make this constituent a member of a group relating to that company.

I would like to see only one instance of an address, email address or phone number on the system to which multiple parties gain access over time (by attempting to put it in themselves subsequently). Our database is riddled with multiple duplicate addresses all of which are exactly the same but which have been entered in by different members of the same organization in some cases or different organisations in the consortium. However, there will be some nervousness that a user from Org A will change the address subsequently and mailouts from Org B will end up at the wrong address because they operate with different business rules. This might make this out of the question.

Just some thoughts!

David

David Joyce Tessitura Business Analyst

djoyce@sydneyoperahouse.com

T+61 2 9250 7625  F+61 2 9251 7821  M 0423 780 014

SYDNEY OPERA HOUSE BENNELONG POINT

GPO BOX 4274, SYDNEY NSW 2001, AUSTRALIA

SYDNEYOPERAHOUSE.COM

One of our assumptions has been around the idea that a Next Generation constituent needn't necessarily have a postal address.  As many of you know this requirement in the current software has caused us to jump through some hoops with web registrations where we actually temporarily create constituents with a dummy address.  So the thought was if a large percentage of your constituents only address you electronically, why bother with a required postal address?  Furthermore, considering the type of "groups with members" constituent model that we've been talking about, why should a every child in a family need an address when all of the children belong to a family that has a postal address?

So yesterday we got into having a big discussion about whether we needed to carry on the notion of a "primary address" for a constituent.  Currently each constituent must have a primary address and that primary address must not be control grouped--everyone can see it. 

Primary addresses has some nice advantages--if you want to analyze purchasing by postal code sometimes you just need any easy way to get to a postal code.  Plus if you've got several addresses on a constituent and none of them really match the criteria for a particular mailing, you've always got the primary address to fall back on.

Obviously if no postal address is required then you can't force a primary address.  You could make a rule like "if there are any addresses, then one of them must be primary".    But then we thought, "does this work in a consortium setting"?  Let's say the Symphony and the Ballet share a system.  Couldn't you make the case that the Symphony might want to store a private address that only the Symphony could see?  And that's the only address the constituent has on file?  You can't say it's the primary address because the Ballet can't see it. 

So several questions:

1.  What about this notion of a constituent with no postal address?  Does that make sense?  Or does the current model feel better?  Even with the group/member model we could say that each constituent has to have a primary address, even if that address is not specifically tied to that constituent.  That's the example of the child's primary address actually being the family's address.

2.  If there were no requirement for a postal address, then there are obviously still times when one is required.  We couldn't have a delivery method of "Mail" if the constituent didn't have an address.  Of course we could require that an order have a shipping address before allowing that delivery method.  But what does this do to subscribers if some percentage of subscribers didn't have postal addresses?  Or is this just the way the world is going and we have to learn to operate that way?

3.  If we don't require an address, what about a primary flag?  Is it ok for a constituent to have say 3 addresses (some shared, some not) and none of them being a primary address?  Is it ok for a constituent to have 3 addresses, all only visible for some part of a consortium?

Believe me it's a nice feeling knowing that we can put questions like this in front a large, interested audience.  We're eagerly awaiting your help.

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!

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=====

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!

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!