Primary Addresses

Hi Chuck

Some thoughts:

1.  What about this notion of a constituent with no postal address? 

- Definitely something we would be interested in, for email newsletter registrations, child accounts, employees of the same company etc.

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.  

Could you have different 'levels' of constituent record - for example if someone is an email newsletter subscriber only we don't need an address but we do need an email address; if someone is a child they don't need an address but do need to be connected to a non-child account that does; if someone is making any kind of payment we need an address for fraud prevention purposes.

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?

I can forsee some issues with this in that it could be easy to send tickets to the incorrect address through human error. However if a pop up box forced choice of an address then this would be all but eliminated.

Hope that helps some

Siobhan

Chuck,

I think the idea of a constituent with no postal address is absolutely something that needs to be incorporated.  I can easily envision patrons whose entire relationship with the organization is electronic.  Between print at home tickets, kiosks, using your cell phone as your ticket, online donations, SMS donations, etc there is less and less reason to deal with postal addresses.

I can even forsee some organizations actively pushing their patrons away from postal addresses because of the cost of producing and mailing physical material and the overhead of maintaining an NCOA compliant database.  Postal costs have been rising and I don't see that trend changing.

With all of that said, you obvioulsy need postal addresses for some things but they take on a different purpose.  Billing addresses for credit cards for instance.  This was mentioned in another thread I believe.  It would be great to have an address that served no purpose other than as a billing address for a credit card.  Ideally, you could associate a different address with each card so that someone could use their business AmEx card to get tickets to one event and their personal Visa for another.

I also like the idea of consortium members having seperate addresses without the need to have a common "primary" address for the constituent. From an NCOA perspective, it would be great if the process was smart enough to recognize that there are 3 identical addresses on an account, export that address once and then update all 3 when the results are uploaded.

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.

Unknown said:

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.

In my version of Utopia, we wouldn't be mailing paper, we would be electronically transferring information.  I think that day will come, however, in my current world - Opera -  that day is many years away.

That said, I agree with most of you that it would be totally ok to have constituents without postal addresses as long as there is some other identifying address - email, phone, etc.  I wouldn't want a database full of John Smiths without any distinguishing information.

I personally like the idea of a primary flag for postal addresses.  It certainly makes analysis easier.  In the case a constituent who has several residences it can also give you an indicator of which one they call home.

A few more thoughts just popped into my head regarding allowing records with no address.  I agree with all the other posters that, with the way the world is, we need to allow this.  I wonder, though, how we can balance the need for address-less records with the desire to keep our database as duplicate free as possible.  i.e. How do we dupe check accounts with no address?  Obviously the requirement of searching by last name and zip before creating a new record won't work.  Or do we not worry about it until a no-address account makes a purchase which requires an address and dupe-check at that point?  And how do we configure our constituent search to easily access and show all account information, not just name and address?

I agree that we need a way to store records with no postal address. It would be great to have the system allow the storing of Zip codes almost like source codes so that even when you aren't building a record, say in the time right before a performance starts, you could still collect Zip data to analyze.

If there was a way to require addresses based on the type of transaction being processed (e.g. selling a package, paying by credit card, selecting Mail as delivery method, etc.) then you could address the individual organizations business practices without having to always require a postal address in every record.

The difficulty I'm seeing in not having a shared primary address is a shared box office in a consortium.  If there is no Primary address that is shared amongst the organizations you run the risk of one organization not being able to see the address of the person that bought tickets to their event simply because the wrong type/control group was set for the address.  I also wouldn't want a ticket seller to have to associate an address to every order they process.  If there is only one address in the record then this is easy, but as soon as you add a second address (at any organization) if there is no primary flag then the seller has to associate an address to the order. 

I would love to be able to set the primary flag for each organization, but would that mean that Org A that runs the main box office sells a ticket to Org B's production and the address that gets associated is now A's instead of B's and B cannot see the address of their constituent or the seller has to have access to all organizations addresses and we are back to them having to select an address on every order, sometimes looking through the same address multiple times and having to figure out which is the correct one.  

Also, how would this translate out to the web?  With no primary address would the web show all addresses associated to the record for all organizations or would we have to specify which addresses can be shown on the web?

This discussion ties to a couple of things I've been thinking about, so I'm going to branch off just a bit in an effort to answer your questions.

1. In our office we have been thinking about how best to mark the account of a patron who has expressed a preference for email communication (for example). We may still have the option of sending postal mail or calling them, but their preference is email. To tie this to the thread, what if rather than "primary address" Tessitura required a "primary channel of contact"? I'm not sure what the best title for that is, but this would accommodate patrons who have provided only an email address, or only a phone number, and could also help us manage medium preferences.

2. While I'm on the subject of preferences: We have not used the mail preferences feature of the existing system, and have used address types very minimally, because there is a very real concern (widespread and not unfounded) that they will not be consistently used or properly maintained. This means that the primary address is very important for us because it's the default that we use almost all the time. We may want to rethink this business practice as we move to the new system, but I hope that we can retain a way to mark the default mailing address when there is more than one address on the account. (And a default phone, and a default email, etc. as needed.)

Finally, for what it's worth, I think address maintenance could benefit from more pop-ups like the one Siobhan mentioned to minimize human error or neglect. If you're updating an address, a pop-up could remind you to also update preferences if needed or update the same address as it appears in a different format. If you're running an extraction or report, a pop-up could remind you to select a particular address type if needed. We might trust ourselves more if we had these reminders, and if we could trust our correct use of a variety of addresses it would be less critical to have a Primary one.

Sarah

Thanks for the great thoughts.

A question specifically for consortiums:  If we make an address optional, but if you have one you must have a primary one, then does the requirement that the primary address be visible to all still work?

I most concerned with that consortium case where you've got a constituent that doesn't have an address and then one org says "ok now we've got a private address and we want it to stay private".  If we require a non-control grouped primary address (if there is an address at all), then that's not possible.

Thoughts?

Ok, say you have three organizations each with their own primary address.  Then you have a central box office that can see all addresses.  So they see three primary addresses.  All of sudden, primary doesn't seem primary any more.   That's the dilemma that I keep bumping up against.

And that would be the issue we would face since we do have a central box office. We would almost need to treat the central box office as it's own entity. In our case, if our central box sells a ticket to a show, they manage that order. Even though the ticket may be to my performance that I am presenting, I do not have access to the order but I do have the capability to report on the sale.

Therefore it would make since that the box office would need to have their own default addresses. Maybe these addresses can be seen by all or maybe just by the central box office. It's a coin toss for me.

If I had a "Private Address", In our current system, I would set up each organization with a minimum of two control groups. One where all of the seasons get set up that the central box office has access to all of them but the other control group would be for the organization only and this is where I would put the "Private Address" and the central box office and everybody else can not see.

Thanks,

Marty