Keepting track of contacts

Options
Hello all, My boss wants me to keep track of his contacts, without using solicitors or constituent codes. I thought of using relationships or attributes. If I use relationships, what relationship and recripocal should I use? Contact as relationship? What about recripocal? How do you all track these? Thanks, Ida

Comments

  • Ida Martyrossian:
    Hello all, My boss wants me to keep track of his contacts, without using solicitors or constituent codes. I thought of using relationships or attributes. If I use relationships, what relationship and recripocal should I use? Contact as relationship? What about recripocal? How do you all track these? Thanks, Ida

    Solicitor probably isn't the best answer, but why doesn't your boss want you to?

     Certainly wouldn't use Constituent Codes. 

    If you use relationships, maybe Contact and Contactee?  [;)]  Or President's Contact (or whatever your boss' title is)?  

    Or use an attribute, perhaps it can fit into another attribute you already use?  Do you track mailing lists (newsletters?) in attributes?  If so, treat it just like any other mailing list.  

  • Ida Martyrossian:
    Hello all, My boss wants me to keep track of his contacts, without using solicitors or constituent codes. I thought of using relationships or attributes. If I use relationships, what relationship and recripocal should I use? Contact as relationship? What about recripocal? How do you all track these? Thanks, Ida

     I have had to do the same thing.  There is oftentimes a specific group of peeps that your boss will want the ability to include in certain invitations or asks, but does not want them to get ALL the collateral that is pushed out by your organization.  I have found, in several situations, there are one or two significant individuals on campus president, VP. 

     Best thing to do, and most direct way to pull them into queries.  An attribute of Special List and your boss' name  Joe Smith Contact or Jane Doe Contact.  That way if/when they leave the organization you can  identify immediately why they were involved in the first place and archive them upon boss exit or retirement.

  • Christine Cooke:

     I have had to do the same thing.  There is oftentimes a specific group of peeps that your boss will want the ability to include in certain invitations or asks, but does not want them to get ALL the collateral that is pushed out by your organization.  I have found, in several situations, there are one or two significant individuals on campus president, VP. 

     Best thing to do, and most direct way to pull them into queries.  An attribute of Special List and your boss' name  Joe Smith Contact or Jane Doe Contact.  That way if/when they leave the organization you can  identify immediately why they were involved in the first place and archive them upon boss exit or retirement.

     Thank you Christine!

  • Josh Bekerman:

    Solicitor probably isn't the best answer, but why doesn't your boss want you to?

     Certainly wouldn't use Constituent Codes. 

    If you use relationships, maybe Contact and Contactee?  [;)]  Or President's Contact (or whatever your boss' title is)?  

    Or use an attribute, perhaps it can fit into another attribute you already use?  Do you track mailing lists (newsletters?) in attributes?  If so, treat it just like any other mailing list.  

     Well, he's not soliciting them at the moment, that's why he doesn't want to use solicit codes. Thank you for your suggestions!

  • Ida Martyrossian:

     Well, he's not soliciting them at the moment, that's why he doesn't want to use solicit codes. Thank you for your suggestions!

    Just to clarify, Solicit Codes are not necessarily just FOR soliciting someone, but about HOW to (or not to) solicit. (see KB BB24742). For instance, you could create a solicit code for "No Solicitations" or "Newsletters Only" to know exactly how to pull for mailings. In your case, you could easily create a solicit code called "Personal Contact ONLY" or even "ED Personal (Jim)" and use those codes to filter ANY mailings, exports, queries, etc. I know that solicit codes can be a big flag because many RE admins check those upon starting with an org to be sure they understand the exceptions when they pull lists. But of course there are a variety of ways to get this done, and I agree with Josh and Christine that attributes would also be an effective way to do this. Most important is developing a policy to create consistency - especially when pulling names for mailings/queries.

Categories