Addressing addresses

We would like to be able to rank address types when extracting them.

Story: Say, hypothetically, that Opera Company operates in a consortium.  The marketing manager mails out thousands of subs brochures.  Some recipients have a number of address types eg Opera Board Address (home address, maintained by CEO's office), Opera Donor Address (home address, maintained by Development department), Consortium General address (maintained by Box Office operators across the consortium).  She needs to create a list with the most correct address for each constituent, order of priority eg if constituent has a Board address, select that; if not, select Donor address; if not select General address etc.

AND she needs correct salutation with each address type, so the salutation allocated to that address can, if she chooses, be extracted with it.

AND she needs to have access to all these addresses and salutations to extract them, even though she may not have user rights to edit them (here, we cross into control-grouping territory).

Just ran into another one:

I need to run the membership renewals utility, and exclude bad addresses.  If the address is inactive, no problem; but since you can't inactivate a primary address, and you must have a primary address on all accounts, this leaves me with a problem.  I could run a list of bad addresses (which, incidentally, would be looking for both "NCOA$DNM" coding as well as another technique that we can use to mark bad addresses ad hoc)...trouble is, I need to use my list filtering option to segment my renewals for tailored messaging.  Having to use it for both makes the whole process much more complicated. 

Moral: any address marking (eg for bad addresses) needs to carry through ALL aspects of the db systematically.  Once you mark something bad in one of the standard ways, you should never have to wonder if it will be excluded - you should know it will be.

I've been thinking about addresses and noticing that Development departments seemingly everywhere are much-maligned in their attempts to "manage" addresses in their own ways. Thought I might share some of my thoughts, from that point of view. =)

Keep in mind that Lyric's IS Director recently asked me if I'd "gone over" and "finally seen the light" about letting everything be QAS'd - to which I answered "No." But that got me thinking about why - because obviously it is a ton of work with a fair amount of duplicate effort to accommodate separate addresses.

So we looked at our database - 1.3% of the active customers in our database had more than one active address. Of those - the percentage jumped to 6.3% of our customers with our what I will lump together as "important" constituencies. Then, when I looked - we aren't managing separate/additional address locations, necessarily. The number one thing we are doing is managing a STYLE of addressing.

Example - an Invitation Address -- all the data is exactly the same - but it appears differently: "Mr. and Mrs. James C. Pritchard" (not JIM AND BONNIE) and "Street" (not ST with no period) are written out. Right now we select this via a combination of Formal Invitation Salutation Type and Mailing Purpose of "I" (for Invitation). It's not really a purpose, though. It's a STYLE.

I think that Purposes and Styles are different. Could Purposes contain Different Data?? E.G. Invitation Purpose would be the home address instead of the corporate address?? And then Styles could be an "overlay" that did lovely looking, Development Department-approved formats of the same information?? To me that would save a lot of time in invitation review, etc. by not having to update and audit if a home address changes, you have to change and modify all the addresses.

One of the examples that we struggle with Addresses is with Invitations when a corporate-type Board member wants his invitations to go to his house so that his wife knows what is going on - or, he might want TWO invitations to be sent - one to the office to his assistant who manages his calendar, and one to his house so his wife knows what is going on and what to wear. We manage this really well with a series of Attributes right now, but it would be nice not to have to.

I am just talking here - I'm not trying to muck up things, as obviously a number of address management issues would need to be reworked, and this is the beginning of an idea. But, frankly, they will have to be reworked anyway if the constituent model is going to look different than how it does now, so we might as well talk about it. So, have at it, friends.

Erin

I second many, many of the issues already listed here!  Especially, Rebecca's point about ranking multiple address types (this is a HUGE issue for us here at Yale) and Erina and Tom's points about multiple address types/purposes/styles etc.

We have not made use of the Mail Purpose flags in our consortium, mostly because by the time we divide them up among the consortium members, there really aren't enough of them to be useful.  As a result, we are using Address Types for everything, including different addresses, different styles of addresses, and different uses for addresses, not to mention addresses that are private to a specific consortium member.

We also are in the practice of keeping old addresses on file as inactive addresses in order to make a historical record of customer addresses available to the users.  This information is especially helpful to our users when they are trying to determine if two accounts are duplicates or if they are two different customers with the same name.

I just came across a new issue that I thought I'd post for your consideration.  After running our first NCOA address check, one trouble area is for people who have "unorthodox" addresses.  The most common examples we're seeing are:

1) Patrons who give us both a street address and a PO Box or RR #.  Historically, these had been entered using both the "Street Address" and the "Optional address" fields. However, the NCOA process "erased" whatever was in the optional address in most of those cases, because the process doesn't consider this two-line address to be the standardized version.

2) Individual accounts for which the patron has a "care of" or "Attention" line.  Again, these had been put in the "Optional address" line, as they are, in effect, optional addresses...the trouble is, NCOA treats them as "un-standard" and erases them when it standardizes the address.

3) And thirdly, individuals who want to receive their mail at a business address.  They need to be individual constituent types, so we know they are working with us as an individual and not as a representative of the company.  But as an individual, the only data lines we have in the address itself are for name 1, name 2, and the main or optional street addresses.  Again, we used to list it in the optional line, but the NCOA wipes that line clean when it standardizes. 

Our workaround for these issues include various tricks...for business names/titles we're using salutations, and for the moment the PO Boxes are just being archived and we're trusting that the mail will reach them at the street address.  But this is not ideal; I think it's a little much to expect every frontline staffer to be fluent in the use of salutations and NCOA so they can fiddle with every "care of" or "send this to me at work" request.

So, for Next Gen, my "story" would be that a patron wants their mail send to them at an address which includes, "care of," "attention," or a company name on their individual record.  The frontline staff has a clean, easy way to enter all that information on the address screen so they can move on to the next patron.  When we pull the NCOA list, it takes account of this information somehow...I suppose that would mean that if the address only needs to be standardized, it won't change this "other info" line at all, but perhaps it will wipe out the "other info" line if it changes the entire address?

Hi Beth,

Thanks for the additional story -- and timely.  We had our first Epic Story Committee meeting on the topic of Addresses this week and this exact concern came up.  We are working through the best way to handle this non-postal-postal-address information.

(P.S. Many thanks to our ESC members who volunteered for the first ESC group.  Many more to come, if you have already joined the ESC keep an eye on the group for more volunteer opportunities.  If you haven't joined the ESC and would like to, you can do so here!)

Andrew