Corporate Contacts

Chris Z

I need some guidance on how to clean up our Corporate Contacts so that the invitation lists reviewed for 2-3 major events each year is not so time-consuming. 


It is important to note that we have several gift officers, each with different contacts in their areas.  I have not been able to get a consensus on defining Contact Types into areas like Primary, Secondary, etc.


I need something more than simply using an Attribute located on the record, because a single attribute on a corporate record will pull multiple contacts on the record.


I was thinking of using Individual Relationship Attributes, and having each of the events named.  Then it would be a matter of marking people as Yes on only those Indiv Rel Attributes that apply.


Thanks in advance for any insight you can share.

Jennifer McHale

Yes. Organizational contacts are the worst.

We did go to relationship attributes for many of our mailings - the individual relationship contacts may be coded for a specific event, newsletter, appeal, etc. I think we tried the Contact Type at one point, but there wasn't always consistency in who was labeled as what - plus, sometimes it's hard to label a person as one "type" when you might want to mail them for different reasons.

It does mean I have to create different Query formats - I often end up with Constituent, Organization, Relationship queries - but merging in Excel at the end of the process is much easier (and consistent) than the manual decision-making process that otherwise was occuring.

Chris Z

Can you tell me more about your different Query formats, and what you mean by that?  I'm not sure I follow.


Thank you.

Jennifer McHale

I prefer to use a Relationship Query to sort out organizational records when I am pulling Attribute Descriptions from the relationship data. I'm often pulling Individuals and Organizations for our mailings, and I find it's hard to review my information if I am mixing and matching so many different types of criteria.

It may just be my personal preference!

Daniel Noga 2

I'll be working with my team to address our own issues with Contacts. In a database that needed lots of cleanup when I started working here, this is probably the most daunting of cleanup tasks.


We are looking to do something very similar to what Jennifer described, and we're doing this cleanup for practically the same reasons everyone else has mentioned already.


We will be foregoing Contact Type for now, because it ropes you into assigning a single type to a given person, and it is not often the case that one of our Contacts can be easily labeled under one or another Contact Type. For example, we have Types of "Main," "Dinner" and "Annual Report." We have some Contacts who are typed "Main" because they are the contact for everything; we have other cases where the person designated "Main" is NOT who we want to receive the Annual Report, so clearly, we wouldn't want to be pulling a mailing list and sending it haphazardly to everyone with a Contact Type of "Main." In practice, we'd been using one field in one system which forces one label onto people, in order to pull different lists for very different purposes. It just doesn't work very well.


Due to the flexibility it will afford us, we'll be using Relationship Attributes instead. Then we will have the freedom to pick and choose who gets what, and we won't be pigeonholed into typing everyone with one-size-fits-all labels that don't really fit anyone. Honestly, the "exceptions" to the rule are greater in number; that is, we have more cases where this nuance will come in handy than we do cases of people we can just slap the "Main" label onto and call it a day.


Once it's all set up and everyone understands how the coding will work, I think it will save us loads of time and agony each year when we print the Annual Report and Dinner mailing lists. It's not just more time-consuming to spend weeks deliberating and doing it manually; the real risk is in losing vital information. People tend not to remember from year to year exactly who got which mailing and why. Far better to set up a system with policies so that the system can do what we got it for: Keep track of this stuff for us.







 

Bill Connors

It is not necessary to have multiple queries or use multiple query types.  Mail and Export can do this (use Contact Attributes) just fine, all at once, using Address Processing, based on a single Constituent query (often a Merge Subtract query).  I agree wholeheartedly with the challenges of Contact Type, so if you're using Contact Address Attributes or Contact Attributes as a backup, that's terrific, but still keep it in Mail (or if you have to, Export) and use Org Address Processing to pull everything once and correctly.

Matt Page

Chris and Daniel,


You might find this thread useful - https://community.blackbaud.com/forums/viewtopic/158/21630 - I had similar problems and found the advice here useful. We add an attirbute called "Mailing Contact" which we add when that's who we want to send mailings to, and use Addess Processing in Export to prioritise those people.


Matt

 

Chris Z

Thank you for the lead to the other posting.  I see the connection, and this all helps me with this project.

Christine Cooke 2

If you are already using Contact Type for Primary, Secondary etc.  And the Contact is in relation to someone in the department that is assigned to maintain the relationship with that person/org -- why not utilize the Assigned Solicitor Relationship?  You can then define when that particular MGO is responsible for that relationship... either by FY or by their tenure in their position as MGO.