Primary Addresses

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

1024x768 Clean false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

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?

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?

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

I like a lot of the suggestions about primary by organization, but every road seems to lead back to the central box office conundrum.

To Marty's suggestion that maybe the central box office owns the order, that wouldn't work in our case where if date/performers change/cancel then generally the presenting organization wants to contact the patron, not have the central box office contact them. 

They also want to be able to solicit them for further sales or donations and if they only have access to the name of the patron (assuming they don't have their own controlled address in the system) then they have no way to do that.  

Perhaps this scenario would work if there could be a way that Org B could say 'show me all addresses associated to Perf X' and the system would allow them to see the information based on the fact that their control group has access to that performance, regardless if they see the address in the actual record.  This way they could still include the address in a postal mailing if desired or they could choose to then associate those addresses to their controlled types using a process that would check for potential duplicates within their controlled addresses.  The issue I see with this is what if the patron bought the tickets as a gift and asked that they be shipped to an alternate address that is not theirs.  I guess you could get around that by adding an additional flag on an address that indicates a gift purchase, but this seems to make things even more complicated.

We definitely need a unique identifier of some kind to come up in the initial consituent search. 

eg Ticket seller is on the phone to customer, Sally Brown.  He types her name into the constituent search - twenty records come up.  Currently, he identifies the correct record by address.  If this is not available, he would need to identify by phone number or email.  Otherwise the operator will be creating Sally Brown record no. 21.

This is a problem for everyone but is exaccerbated in the consortium environment because of the sheer potential for duplication.

Another thought on this:

It would be good for each organisation to be able to specify which fields should be mandatory when a record is created.  We could then ensure that some kind of contact information is captured - either address OR phone OR email.

(Sorry - can't think of a coherent way to turn this into a story.)