Former phone numbers and email addresses

Options
Hi.  If you keep former/old/bad phone numbers and email addresses where do you keep them?  Phones? Notes? Alias? Attributes?  


Looking for feedback on where to keep this information, not whether or not the information should be kept in the first place.


Thanks,

Josh

 
Tagged:

Comments

  • Hi! If you scroll to the right of the email/phone/fax  field, there should be a checkbox that says something like "inactive". I'm not 100% sure what it says because I don't have RE open but I've used it that checkbox this week.

  • Thanks Amy, but we have not upgraded to 7.96 and and do not have those fields yet.


    Thanks!
  • Hi Joshua,


    As per Amy's post, as you no doubt know RE7.94+ is different to previous RE versions with respect to how phones and emails are stored and displayed.


    However, I don't think the practice you adopt for retaining and indicating old/invalid/etc phones and emails changes too drastically.


    Ignoring the ability to simply mark them as Inactive, you can also create your own phone and email types such as Invalid Email, Former Phone - even Email 1, Email 2 and Email 3, etc if you want to keep all your history - and simply use those. In addition, you could conceivably add an Attribute or Note to the effect that the phone or email has been updated and/or why.


    (As I tend to bang on about, this kind of thing can be automated using the optional VBA Module but this isn't available to NXT/hosted customers, and is a not-insignificant additional cost otherwise. Jarod Bonino (Blackbaud) mentions in another recent post that the NXT SKY API will soon support event-driven actions such as this and that will make life easier all 'round, I think.)


    Cheers,

    Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions

     
  • JoAnn Strommen
    JoAnn Strommen ✭✭✭✭✭
    Ancient Membership Facilitator 4 Name Dropper Photogenic
    Haven't updated RE either. We keep just with other phone email records. Just change type to former home, former work, invalid email etc.  Quick and easy to see when given the same # or email that it's not good. 
  • We had quite enough phone types already (around 80 when we first switched to RE, though I've since whittled this down considerably!) without adding more for invalid phones, so up until now we've used the Do Not Contact field for any bounced emails etc. Now we've upgraded to 7.96, I'm going to move all of the DNC data across to the Inactive field as the DNC field cannot be updated in bulk without using ImportOmatic.
  • Joshua Bekerman bCRE:

    Hi.  If you keep former/old/bad phone numbers and email addresses where do you keep them?  Phones? Notes? Alias? Attributes?  


    Looking for feedback on where to keep this information, not whether or not the information should be kept in the first place.


    Thanks,

    Josh

     

     

    Up until we updated to 7.96, I had created an address attribute category of Former Phone (or Email) and kept them in the address tab if the phone or email changed but the address didn't.  The description was the phone number or email address and comments was where the info came from. If the address also changed when the phone changed, they were just kept as a Former Phone or Email on the Former Home address. This procedure kept the Bio1 tab clean but we still had a history of the bad phones/emails.

     

  • Hi Josh-


    Assuming you will update to 7.96 at some point, I'm guessing you'll begin to leverage the inactive checkbox on phones at that time and as such, I would choose a method for storing old phone numbers in a way that allows you to leverage 7.96 features when you get there. I'd second JoAnn's recommendation to store them with a specific Phone Type (e.g., PhoneType = Inactive). When you convert to 7.96 you'll be able to update those phone numbers using the 7.96 inactive feature and can change the Phone Type at that point should you choose to do so.
  • Jen Claudy:

    I recommend Phone Types.  At my last org, I prefixed them with an "x" so something like "xHome Phone" and "xWork Email".  I still used this system after updating to 7.94, because that [Show Inactive Phones] checkbox is not sticky (so once marked Inactive, those Phones will be hidden by default when opening the record) and querying on Phones is difficult when using the Primary/Inactive/DNC options as they are not tied directly to the Phone record (the new Phone Comment field is, however!).  

    Jen,


    THANK YOU for confirming what's been driving us crazy about the new phone setup.  It is next to impossible to do any real querying with phones types anymore!  angry  

  • Basically, what Jen Claudy said. It makes most sense to me to have a "Bad", "Incorrect", and/or "Previous" email/phone types in the phone area, because if I'm looking at someone's record and don't see the email I'm familiar with for a person, I'm not going to look anywhere else on the constituent's record for it. If you have it there and have it marked as incorrect/previous, it takes away a lot of frustration/guess work as to what the status of any give contact info is. You may want to keep a note of WHY something was marked inactive/incorrect/previous, just in case there are any questions, but deleting it from the phone area entirely to put it elsewhere seems like it will only cause more trouble.

  • Thanks for everyone's feedback!  


    Josh

     
  • Joshua Bekerman bCRE:

    Hi.  If you keep former/old/bad phone numbers and email addresses where do you keep them?  Phones? Notes? Alias? Attributes?  


    Looking for feedback on where to keep this information, not whether or not the information should be kept in the first place.


    Thanks,

    Josh

     

    Hi Josh,

    We keep former/bad email addresses as a note called email change. We remove the bad/old email from the phone section in RE (7.95)

    We keep former addresses on the address tab as former address and make a action called mailing information to record the address change.

    Bad or changed phone numbers are kept in the phone table (7.95) and marked inactive with an action to record the change.

     

Categories