Addressing addresses

Wow Andrew...heck of a question for a Friday afternoon!

Marta beat me to the statement about phone numbers being tied to addresses.  Ditto.

One interesting problem that we keep having is the question of logging the address history.  Our development department (who will hopefully correct me if I'm wrong) would prefer that the address history of a patron be easily visible - as it is, beautifully, on the address tab.  The trouble is, our frontline staff are busy people - they don't have time to click over to the address tab, add a new address there, inactivate the old address, and add the new one.  The just need to type in the new address over the top of the old one on the general tab.  Logging the changes in the audit history is helpful, but not as holistic as the address tab.  And of course, it's hard when one segment of the staff needs data that another segment may not be able to take the time to provide.  It would be great if both objectives could be met: perhaps when you "write over" an address, a copy of the previous version is automatically archived into the equivalent of the address tab.  Maybe this is something each institution could set a rule for (either don't archive any, archive all, or offer the "would you like to save a copy" option that comes up in some circumstances now). 

I also find that we have some challenges around bad address management.  For instance, we mark addresses as bad on the address tab with an address type.  That way, the words "Bad address" are displayed on the general tab so the frontline staff can see them, and hopefully get a new address.  The trouble is, if they don't remember to go to the address tab and change that address type, the new address will be marked as bad.  We are just starting to use the NCOA functionality (first list was run by MBS today!), and I *love* how that is set up - if the "last updated" field gets changed, then it gets checked by NCOA again.  No user error can lead to it staying marked as bad if it's automatic like that.  And in general for address functionality, it should match up with how NCOA checking is handled, so staff don't have to learn different systems.  A clunky example: perhaps there's a checkbox of "bad address" which ties to a specific last updated field; if any change is made to the address, the checkbox goes away and it pulls in as a good address until it comes back as bad again, and a related "last updated by" field tells you what user changed it last.

The stories here might be:

Story 1) Rachel in the Call Center gets a caller who mentions that their address has changed.  She just types the new address right over the old one, and moves on with the call. 

Story 2) Meanwhile, I as the Membership Manager need to pull a mailing list, and exclude any bad addresses.  I have some addresses which have been marked as bad by the last NCOA upload; some which have been marked bad by my data entry staff when the last member newsletter bounced back to us; and the account above, which had been marked as bad but just got updated by Rachel.  However, I only have to look at one field to know which addresses to exclude.  The checkbox above will is the only field on which I have to exclude.  The NCOA bad address is marked there with "NCOA" as the last updated user; the account marked bad by my data entry staff has the same box checked, with a different last updated by name; and the address that Rachel just fixed *was* marked as bad, but the checkbox automatically got un-marked and her name was added as "last updated" when she made the correction.

Another example is related to the constituent relationships question: we can have adults on a membership who live at different addresses.  Right now, we just make them give us one "address of record."  But how great would it be if I could KNOW a) whether they live at the same place; b) whether they'd like mail at one address or the other, or both; and c) for bills or other mailings that cannot be duplicated, which address they want use - and pull my mailing lists accordingly? 

Story for this one: I need to pull the mailing list for the member newsletter.  All I have to do is pull a list for all active members, and select some kind of parameter that indicates that I want to allow multiple addresses.  Obviously if both members are at the same address, that address is pulled.  For records with a different address for each name, it checks whether that person wanted both addys used.  If so, each name is pulled onto an independent line with its corresponding address.  If they only wanted mail at one address, it pulls that one.  If I were sending renewal notices, however, I might choose NOT to allow multiple addresses, as I don't want them BOTH to renew - then it would default to one address or the other.

I LOVE LOVE LOVE the idea of address purposes - but give us more please, and let us mark them with more than 1 letter so they are easy to interpret.  Preferably give us a system table where we can add as many as we want.

Those are my thoughts for now...can't wait to see what others think of!

Beth

Wow Andrew...heck of a question for a Friday afternoon!

Marta beat me to the statement about phone numbers being tied to addresses.  Ditto.

One interesting problem that we keep having is the question of logging the address history.  Our development department (who will hopefully correct me if I'm wrong) would prefer that the address history of a patron be easily visible - as it is, beautifully, on the address tab.  The trouble is, our frontline staff are busy people - they don't have time to click over to the address tab, add a new address there, inactivate the old address, and add the new one.  The just need to type in the new address over the top of the old one on the general tab.  Logging the changes in the audit history is helpful, but not as holistic as the address tab.  And of course, it's hard when one segment of the staff needs data that another segment may not be able to take the time to provide.  It would be great if both objectives could be met: perhaps when you "write over" an address, a copy of the previous version is automatically archived into the equivalent of the address tab.  Maybe this is something each institution could set a rule for (either don't archive any, archive all, or offer the "would you like to save a copy" option that comes up in some circumstances now). 

I also find that we have some challenges around bad address management.  For instance, we mark addresses as bad on the address tab with an address type.  That way, the words "Bad address" are displayed on the general tab so the frontline staff can see them, and hopefully get a new address.  The trouble is, if they don't remember to go to the address tab and change that address type, the new address will be marked as bad.  We are just starting to use the NCOA functionality (first list was run by MBS today!), and I *love* how that is set up - if the "last updated" field gets changed, then it gets checked by NCOA again.  No user error can lead to it staying marked as bad if it's automatic like that.  And in general for address functionality, it should match up with how NCOA checking is handled, so staff don't have to learn different systems.  A clunky example: perhaps there's a checkbox of "bad address" which ties to a specific last updated field; if any change is made to the address, the checkbox goes away and it pulls in as a good address until it comes back as bad again, and a related "last updated by" field tells you what user changed it last.

The stories here might be:

Story 1) Rachel in the Call Center gets a caller who mentions that their address has changed.  She just types the new address right over the old one, and moves on with the call. 

Story 2) Meanwhile, I as the Membership Manager need to pull a mailing list, and exclude any bad addresses.  I have some addresses which have been marked as bad by the last NCOA upload; some which have been marked bad by my data entry staff when the last member newsletter bounced back to us; and the account above, which had been marked as bad but just got updated by Rachel.  However, I only have to look at one field to know which addresses to exclude.  The checkbox above will is the only field on which I have to exclude.  The NCOA bad address is marked there with "NCOA" as the last updated user; the account marked bad by my data entry staff has the same box checked, with a different last updated by name; and the address that Rachel just fixed *was* marked as bad, but the checkbox automatically got un-marked and her name was added as "last updated" when she made the correction.

Another example is related to the constituent relationships question: we can have adults on a membership who live at different addresses.  Right now, we just make them give us one "address of record."  But how great would it be if I could KNOW a) whether they live at the same place; b) whether they'd like mail at one address or the other, or both; and c) for bills or other mailings that cannot be duplicated, which address they want use - and pull my mailing lists accordingly? 

Story for this one: I need to pull the mailing list for the member newsletter.  All I have to do is pull a list for all active members, and select some kind of parameter that indicates that I want to allow multiple addresses.  Obviously if both members are at the same address, that address is pulled.  For records with a different address for each name, it checks whether that person wanted both addys used.  If so, each name is pulled onto an independent line with its corresponding address.  If they only wanted mail at one address, it pulls that one.  If I were sending renewal notices, however, I might choose NOT to allow multiple addresses, as I don't want them BOTH to renew - then it would default to one address or the other.

I LOVE LOVE LOVE the idea of address purposes - but give us more please, and let us mark them with more than 1 letter so they are easy to interpret.  Preferably give us a system table where we can add as many as we want.

Those are my thoughts for now...can't wait to see what others think of!

Beth