Primary Addresses

Chuck

 

A response to your questions.

 

--Tom Brown

IT Project Manager

Brooklyn Academy of Music

1.      What about this notion of a constituent with no postal address?  Does that make sense? 

a.       I think that this makes sense.

2.      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.

a.       You sort of need to have this idea of where to look for an address for each constituent.  When trying to send out a Mail

                                                              i.      First I look for a primary active address attached to the Constituent if one is marked Primary for my organization.

1.      This makes it clear when a Constituent has more than one address.

2.      Maybe you ONLY need to mark an address as primary when there is more than one address that an organization can see.

                                                            ii.      Then I look at any active address on the Constituent weather it is marked Primary or not.

                                                          iii.      Then I look for a primary active address on the group that my organization has set.

1.      This makes things clear when a group has more than one address

                                                          iv.      Then I look at any active address for the group that my organization can see

                                                            v.      Otherwise this constituent has no address.

1.      And I think that it is OK that this is the way things are.

2.      My organization may only have an email address for this particular constituent.  And we may have never sold anything to this particular constituent.

3.      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.

a.       Yes.

4.      Of course we could require that an order have a shipping address before allowing that delivery method?

a.       Yes,  Absolutely

5.       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?

a.       If you are a subscriber and My organizations business process says that I have to have an address to put in an order than the system provides either the subscribers address or the groups addresses.  And I think that is OK.

6.      If we don't require an address, what about a primary flag? 

a.       Primary flag is only needed when there are 2 or more addresses on the account that I can see in my organization.  (This is going to be tough in a Consortium.)  So you get into the Idea that the address is primary for an organization or a primary control group or something like that.)

7.      Is it ok for a constituent to have say 3 addresses (some shared, some not) and none of them being a primary address?

a.       I would argue Yes.  Because we will look for valid address as described above.

8.      Is it ok for a constituent to have 3 addresses, all only visible for some part of a consortium?

a.       Yes, and we use the logic above to find the best address for the consortium user.

b.      If the consortium has a model that we share addresses across all members (that is one of the benefits of a consortium member) we need a method to share that address.

 

The one thing I do see happening with the above is that there could be several active copies of the same address for a constituent or Group that are exactly the same.  My initial response for this is disk space is cheap.  However, this potentially ups a consortiums cost for NCOA.  You probably end up sending out the same address for the same constituent several times, once for each consortium member.

 

--Tom

 

 

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

 

A response to your questions.

 

--Tom Brown

IT Project Manager

Brooklyn Academy of Music

1.      What about this notion of a constituent with no postal address?  Does that make sense? 

a.       I think that this makes sense.

2.      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.

a.       You sort of need to have this idea of where to look for an address for each constituent.  When trying to send out a Mail

                                                              i.      First I look for a primary active address attached to the Constituent if one is marked Primary for my organization.

1.      This makes it clear when a Constituent has more than one address.

2.      Maybe you ONLY need to mark an address as primary when there is more than one address that an organization can see.

                                                            ii.      Then I look at any active address on the Constituent weather it is marked Primary or not.

                                                          iii.      Then I look for a primary active address on the group that my organization has set.

1.      This makes things clear when a group has more than one address

                                                          iv.      Then I look at any active address for the group that my organization can see

                                                            v.      Otherwise this constituent has no address.

1.      And I think that it is OK that this is the way things are.

2.      My organization may only have an email address for this particular constituent.  And we may have never sold anything to this particular constituent.

3.      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.

a.       Yes.

4.      Of course we could require that an order have a shipping address before allowing that delivery method?

a.       Yes,  Absolutely

5.       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?

a.       If you are a subscriber and My organizations business process says that I have to have an address to put in an order than the system provides either the subscribers address or the groups addresses.  And I think that is OK.

6.      If we don't require an address, what about a primary flag? 

a.       Primary flag is only needed when there are 2 or more addresses on the account that I can see in my organization.  (This is going to be tough in a Consortium.)  So you get into the Idea that the address is primary for an organization or a primary control group or something like that.)

7.      Is it ok for a constituent to have say 3 addresses (some shared, some not) and none of them being a primary address?

a.       I would argue Yes.  Because we will look for valid address as described above.

8.      Is it ok for a constituent to have 3 addresses, all only visible for some part of a consortium?

a.       Yes, and we use the logic above to find the best address for the consortium user.

b.      If the consortium has a model that we share addresses across all members (that is one of the benefits of a consortium member) we need a method to share that address.

 

The one thing I do see happening with the above is that there could be several active copies of the same address for a constituent or Group that are exactly the same.  My initial response for this is disk space is cheap.  However, this potentially ups a consortiums cost for NCOA.  You probably end up sending out the same address for the same constituent several times, once for each consortium member.

 

--Tom

 

 

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!

I really recent Radio Shack’s request for Zip code.  I tend to refuse to provide that information or give them bogus data.  I do not want to have that kind of “close” relationship with Radio Shack.  I also don’t use a credit card with radio Shack,  I tend to use cash.  In your case with an origination requirement to collect ZIP code, If address is optional I would think in this case you would add an address that only has zip code.  Then as the relationship with the customer deepens, you fill out the rest.  However, I would expect that you would want to put some type of address type on an address record that does not represent a usable communications channel.  Maybe set an address type so that it is clear that it is only a partial address and not to be used by the marketing department to print out address labels.

 

--Tom

 

 

Levi Sauerbrei:

Your comment on analyzing purchase habits by Zip Code are on the nose as well, but we don't really need the whole address for that.  I am often asked during point of sale purchases to provide a Zip Code (Radio Shack is notorious for this, but many other reatil outlets do the same thing).  I would imagine that venues which do a lot of walk-up business would love to have this type of information to analyze but I don't think there is a efficient way to execute it in the current model.

Hear, hear!  This has been on our wishlist for quite some time.  We're currently able to capture this data using Order Category, but it's clunky and the biggest challenge is integrating this data with the actual address data to get the whole picture.