Addressing addresses

Erin,

The idea of an address Style resonates with what I am seeing here.  And the separate idea of address purpose (what we are to send to each address).  Thickets, Invitations, Contribution acknowledgements covers a lot about the small number of situations when we have multiple addresses.

We also have multiple addresses because we have kept old addresses as inactive when people move and we get this information as part of the NCOA process.  In the long run we think this can give an interesting long term perspective on a potential customer.  (This customer moved from a less affluent area to a more affluent area, and then back to a less affluent location.  Or the customer repeatedly moves from NYC to Florida and back again.)  However, we are likely to move away from this because it has been complicated to keep this data and the new Tessitura Network provided NCOA process does not permit this kind of process.

--Tom

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

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.

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!