Should everyone have a constituent code?

Suzanne Smith

We do not currently give constituent codes to general donors or members. This might help with some reports though, and I am considering adding a Member and Donor code. However, this means the dates for the codes will have to be updated annually. Your thoughts are appreciated!

Joshua Bekerman bCLO bCRE

Suzanne Smith:
We do not currently give constituent codes to general donors or members. This might help with some reports though, and I am considering adding a Member and Donor code. However, this means the dates for the codes will have to be updated annually. Your thoughts are appreciated!

Do you already have constituent codes for foundations and corporations?  If so then you should probably have a code for "Individual"

You already know they are a donor if they have gifts on their record, so having "Donor" as a constituent code would, in a way, be entering the same information twice.

Same goes for members.  Hopefully you have the membership module and are tracking membership information there. So again, entering a constituent code of "Member" would be entering the information twice, in two different places.  Also, keeping the dates updated would be a headache you don't need.

(Yay!  My 300th post!  [8-|] )

Melissa Graves 2

Suzanne Smith:
We do not currently give constituent codes to general donors or members. This might help with some reports though, and I am considering adding a Member and Donor code. However, this means the dates for the codes will have to be updated annually. Your thoughts are appreciated!

I haghly discourage people from using Donor and Member codes. They will require so much maintenance and you already know they are a donor or member based on giving information and membership information.

For those who are not in another category I use Individual. You could use "friend" or "community member" but it should in general terms mean this is an individual with no other identified constituency.

Suzanne Smith

Melissa Graves:

I haghly discourage people from using Donor and Member codes. They will require so much maintenance and you already know they are a donor or member based on giving information and membership information.

For those who are not in another category I use Individual. You could use "friend" or "community member" but it should in general terms mean this is an individual with no other identified constituency.

Thank you Josh and Melissa! That's exactly what I was thinking. Individual would solve the problem for reporting perfectly!

JoAnn Strommen

Suzanne Smith:
Thank you Josh and Melissa! That's exactly what I was thinking. Individual would solve the problem for reporting perfectly!

For us, constitutent code is a required field. I understand the perspective that entering a code of donor can be double work - but to me so is entering "individual"   We do use a constituent code of 'donor,' Branch A donor,' 'Branch B donor'.

We record gifts for primary Y and two branches as well as run annual campaign, endowment, capital campaigns and have some memrorial donors and event donors.  For us having this constituent code is easier than querying time to include/exclude donors to certain campaigns. 

I'm not following why the constituent codes would need to be updated annually for donors.  Yes, with a member code.

I have constituent code displayed in the constitiuent field panel while working in batch and can make any adjustments needed.

Just my 2 cents, it works well for us.

Karen Hartt

Suzanne Smith:
We do not currently give constituent codes to general donors or members. This might help with some reports though, and I am considering adding a Member and Donor code. However, this means the dates for the codes will have to be updated annually. Your thoughts are appreciated!

Hi Suzanne, My 2 cents. We are a community foundation and make grants to other nonprofit organizations and students. We use RE for our grantee contact database as well as our donor database so we have many nonprofit organizations in RE along with students. We do use constituency codes, and assign codes based on the question why someone is in our database, but we don't use a donor code. We have codes for Board members, grant requestor, grant payee (these include scholarship applicants), we have codes for media outlets, and others relationships to the foundation. Yes, I know this is not how constituency codes were "intended" to be used, but the system works for us and you should code your constituents the way it works best for your organization. Karen

Gina Gerhard

Karen H. Hartt:
Hi Suzanne, My 2 cents. We are a community foundation and make grants to other nonprofit organizations and students. We use RE for our grantee contact database as well as our donor database so we have many nonprofit organizations in RE along with students. We do use constituency codes, and assign codes based on the question why someone is in our database, but we don't use a donor code. We have codes for Board members, grant requestor, grant payee (these include scholarship applicants), we have codes for media outlets, and others relationships to the foundation. Yes, I know this is not how constituency codes were "intended" to be used, but the system works for us and you should code your constituents the way it works best for your organization. Karen

Haven't been following this thread too closely, but I'll throw into the mix the use of the primary vs. other constituency codes.

We've set up the primary constituency code (which would be the first one entered at the top of the grid) to be our most simple categorization of our constituents.  We then have additional constituency codes that we enter below the primary. 

• 
  
  In query (and I believe also in export?), you are able to distinguish between the two different types of constituency codes which can be helpful when needing to categorize your data. 
  
  
• 
  
  Sometimes we will "chunk" by the primary code only; other times we'll pull by ALL the constituent codes present on the record.
  
  

To make this distinction clear when entering the codes, we've set up our constituency code table with headers. So those who enter records know they need to pick the primary code from the 1st two categories (Individual and Organization); for an individual record, you pick those two values in that category; for organization record, you pick the values in the organization section.  Then you can add secondary codes from those that are below, if applicable.

--INDIVIDUAL--

Individual

Student

--ORGANIZATIONS--

Corporation/Business

Foundation-Community

Nonprofit Organization"

Trust

Estate

....

--SECONDARY--

Opinion Leaders

Grant Requestor

....

Also, I'll audit to make sure that the primary code has been selected from only those primary values and not the secondary ones, and fix any data that got entered incorrectly.

Joshua Bekerman bCLO bCRE

Karen H. Hartt:
Hi Suzanne, My 2 cents. We are a community foundation and make grants to other nonprofit organizations and students. We use RE for our grantee contact database as well as our donor database so we have many nonprofit organizations in RE along with students. We do use constituency codes, and assign codes based on the question why someone is in our database, but we don't use a donor code. We have codes for Board members, grant requestor, grant payee (these include scholarship applicants), we have codes for media outlets, and others relationships to the foundation. Yes, I know this is not how constituency codes were "intended" to be used, but the system works for us and you should code your constituents the way it works best for your organization. Karen

Our constituent codes tie directly back to how we group income on our financial reports and that cute little pie chart found in our Annual Report.

Nina Williams

Suzanne Smith:
We do not currently give constituent codes to general donors or members. This might help with some reports though, and I am considering adding a Member and Donor code. However, this means the dates for the codes will have to be updated annually. Your thoughts are appreciated!

 I do believe that every record should have a constituent code too.  We are a bit different in that we are a school.  Our individuals are broken down to Alumni and Friend.   Then broken down a bit further if a board member.  We also have Foundations, Corps, Orgs, etc.  Much of my reporting and tracking is based on constituency so this is a mandatory field. 

Melissa Graves 2

Nina Williams:

 I do believe that every record should have a constituent code too.  We are a bit different in that we are a school.  Our individuals are broken down to Alumni and Friend.   Then broken down a bit further if a board member.  We also have Foundations, Corps, Orgs, etc.  Much of my reporting and tracking is based on constituency so this is a mandatory field. 

You are all now making me regret NOT submitting a presenter application for a BBCON session on constituent codes. I have heard since though that another popular presenter has so hopefuly there will be a session on this at BBCON.

a) Primary constituent code is NOT strictly equal to the one at the top. That is so untrue. it is the one closest to the top with the appropriate date range for either today or the date range you using in your report. If you are choosing not to get full functionality from RE and not use dates - then it will pull the top one but that is SO not my recommendation for using RE constituent codes.

b) If you have any kind of "donor code" (major donor, XYZ fund donor, branch B supporter, etc.) then you are doing double work, leaving yourself open to error and wasting time in my opinion. It is just as easy to query on constituents with gifts to XYZ fund as it is to query on constituents with XYZ fund donor constituent code. And what happens when someone adds a gift to XYZ fund and neglects to add the constituent code? Double work and unnecessary. If you can query on the two ways that you are recording this and possibly get two different sets of results - don't have two ways to do something.

Gina Gerhard

Melissa Graves:

You are all now making me regret NOT submitting a presenter application for a BBCON session on constituent codes. I have heard since though that another popular presenter has so hopefuly there will be a session on this at BBCON.

a) Primary constituent code is NOT strictly equal to the one at the top. That is so untrue. it is the one closest to the top with the appropriate date range for either today or the date range you using in your report. If you are choosing not to get full functionality from RE and not use dates - then it will pull the top one but that is SO not my recommendation for using RE constituent codes.

b) If you have any kind of "donor code" (major donor, XYZ fund donor, branch B supporter, etc.) then you are doing double work, leaving yourself open to error and wasting time in my opinion. It is just as easy to query on constituents with gifts to XYZ fund as it is to query on constituents with XYZ fund donor constituent code. And what happens when someone adds a gift to XYZ fund and neglects to add the constituent code? Double work and unnecessary. If you can query on the two ways that you are recording this and possibly get two different sets of results - don't have two ways to do something.

Melissa - Thanks for the clarification, since I've never had the situation where I could associate dates with our constituent codes I always thought it was the code in the top position. Good to know.

 Just wondering, what if you had only two codes and they had the exact same date ranges, which would be the primary?

JoAnn Strommen

Gina Gerhard:

Melissa - Thanks for the clarification, since I've never had the situation where I could associate dates with our constituent codes I always thought it was the code in the top position. Good to know.

 Just wondering, what if you had only two codes and they had the exact same date ranges, which would be the primary?

If same date ranges, the top would pull as primary.  (From Melissa's post: it is the one closest to the top with the appropriate date range for either today or the date range you using in your report.)

Definitely agree with using dates for constituency codes. 

Melissa Graves 2

Gina Gerhard:

Melissa - Thanks for the clarification, since I've never had the situation where I could associate dates with our constituent codes I always thought it was the code in the top position. Good to know.

 Just wondering, what if you had only two codes and they had the exact same date ranges, which would be the primary?

To go further and they had different date ranges and the report you were generating had a date range strictly within the second constituent codes range - the primary code that they would count in on that report would be the SECOND one - NOT the first.

Julianne Coleman

Suzanne Smith:
We do not currently give constituent codes to general donors or members. This might help with some reports though, and I am considering adding a Member and Donor code. However, this means the dates for the codes will have to be updated annually. Your thoughts are appreciated!

I don't think Individual should be used as a constituent code, even though just about every non-profit I have been at has used Individual. You already know an Individual record is an Individual - I think the constiutent code should reflect more on how that donor was aquired.

Also, I know there are concerns with using dates with constituent codes, as well as not using dates. What problems do you encounter if you don't use dates and have multiple constituent codes for a record in Raiser's Edge?

 

Thanks

Julianne

Melissa Graves 2

Julianne Coleman:

I don't think Individual should be used as a constituent code, even though just about every non-profit I have been at has used Individual. You already know an Individual record is an Individual - I think the constiutent code should reflect more on how that donor was aquired.

Also, I know there are concerns with using dates with constituent codes, as well as not using dates. What problems do you encounter if you don't use dates and have multiple constituent codes for a record in Raiser's Edge?

 

Thanks

Julianne

Individual is a perfectly acceptable consitutent code. If you follow Bill Connors' "avoid the fruit bowl" advice in his book Fundraising with the Raiser's Edge, you would probably not use how an individual was acquired unless EVERY record had constituent code reflecting source. If you use codes like Foundation, Corporation, etc. mixing in source codes for individuals is exactly the fruit bowl we do not want.

What concerns are there with using dates? I have never heard a valid arguement that there are ever problems when you use dates. Ever. The software functions as designed with dates. When you do not use dates (and sometimes when you use fuzzy dates) the software can give you unexpected results.

JoAnn Strommen

Julianne Coleman:

I don't think Individual should be used as a constituent code, even though just about every non-profit I have been at has used Individual. You already know an Individual record is an Individual - I think the constiutent code should reflect more on how that donor was aquired.

Also, I know there are concerns with using dates with constituent codes, as well as not using dates. What problems do you encounter if you don't use dates and have multiple constituent codes for a record in Raiser's Edge?

 

Thanks

Julianne

For what it's worth, Julianne, I agree with you.  At the suggestion of our BB support when we converted to RE, we set our constituency codes to answer question of 'why is this record in our database?'  So, we do not use code of individual as that information is already recorded in RE.  They are not in our database because they are an individual but because they are a donor, donor to a branch of the Y, board member, etc.  So, yes, we do use code of 'donor'.  I can hear the gasps from those who don't agree and yes I've read Bill Connor's book but still we choose to do what works well for us.  And horror of horrors we also use a code of 'prospective donor'.  (Maintaining accuracy with that vs. donor is not a big deal with code in batches and a query double check as part of monthly data management/cleansing.)

Why does it work? 

• 
  
  As you said, individual vs. organization is already part of each constituent record.  Already available for query.
  
  
• 
  
  We are able to specify using constit code that person/org is a donor to main Y, Branch ABC donor, Branch DEF donor.  (And yes there's overlap)
  
  
• 
  
  We don't have to include past giving to various funds to determine where the person/org is a donor.  Having to incorporate that in each query for us would be a nightmare.  If it wasnt a constit code, we'd have to add it as an attribute.
  
  
• 
  
  We can also track/include/exclude memorial donors with 'memorial donor' as constituent code as per our procedures, memorial donors do not automatically carry over into our general solicitations. 
  
  
• 
  
  We may have a constituent that gave a memorial gift when board member passed away, using the constituent codes as we do allows us to easily know that this person is a prospective donor without having to run queries excluding memorial gifts. 
  
  

It works for us, I know it might not for others. 

We do track why/how record was acquired/source of record as an attribute with a table of choices.

We generally have a 'from' date for constituency codes and only use the 'to' field when appropriate for that code (no longer board member, staff member.)  We haven't really had issues with the dates as long as user is aware of how date can affect what is pulled.

Just another viewpoint...

Melissa Graves 2

JoAnn Strommen:

For what it's worth, Julianne, I agree with you.  At the suggestion of our BB support when we converted to RE, we set our constituency codes to answer question of 'why is this record in our database?'  So, we do not use code of individual as that information is already recorded in RE.  They are not in our database because they are an individual but because they are a donor, donor to a branch of the Y, board member, etc.  So, yes, we do use code of 'donor'.  I can hear the gasps from those who don't agree and yes I've read Bill Connor's book but still we choose to do what works well for us.  And horror of horrors we also use a code of 'prospective donor'.  (Maintaining accuracy with that vs. donor is not a big deal with code in batches and a query double check as part of monthly data management/cleansing.)

Why does it work? 

• 
  
  As you said, individual vs. organization is already part of each constituent record.  Already available for query.
  
  
• 
  
  We are able to specify using constit code that person/org is a donor to main Y, Branch ABC donor, Branch DEF donor.  (And yes there's overlap)
  
  
• 
  
  We don't have to include past giving to various funds to determine where the person/org is a donor.  Having to incorporate that in each query for us would be a nightmare.  If it wasnt a constit code, we'd have to add it as an attribute.
  
  
• 
  
  We can also track/include/exclude memorial donors with 'memorial donor' as constituent code as per our procedures, memorial donors do not automatically carry over into our general solicitations. 
  
  
• 
  
  We may have a constituent that gave a memorial gift when board member passed away, using the constituent codes as we do allows us to easily know that this person is a prospective donor without having to run queries excluding memorial gifts. 
  
  

It works for us, I know it might not for others. 

We do track why/how record was acquired/source of record as an attribute with a table of choices.

We generally have a 'from' date for constituency codes and only use the 'to' field when appropriate for that code (no longer board member, staff member.)  We haven't really had issues with the dates as long as user is aware of how date can affect what is pulled.

Just another viewpoint...

Gasping - and checking my pulse. :-0

If you are "checking this" as a monthly data management then don't you already have the query you say would be a nighmare?

If I included a donor in a non-donor mailing in the middle of a month because I had not done my audit - someone would have my head. Just my thought.

Julianne Coleman

JoAnn Strommen:

For what it's worth, Julianne, I agree with you.  At the suggestion of our BB support when we converted to RE, we set our constituency codes to answer question of 'why is this record in our database?'  So, we do not use code of individual as that information is already recorded in RE.  They are not in our database because they are an individual but because they are a donor, donor to a branch of the Y, board member, etc.  So, yes, we do use code of 'donor'.  I can hear the gasps from those who don't agree and yes I've read Bill Connor's book but still we choose to do what works well for us.  And horror of horrors we also use a code of 'prospective donor'.  (Maintaining accuracy with that vs. donor is not a big deal with code in batches and a query double check as part of monthly data management/cleansing.)

Why does it work? 

• 
  
  As you said, individual vs. organization is already part of each constituent record.  Already available for query.
  
  
• 
  
  We are able to specify using constit code that person/org is a donor to main Y, Branch ABC donor, Branch DEF donor.  (And yes there's overlap)
  
  
• 
  
  We don't have to include past giving to various funds to determine where the person/org is a donor.  Having to incorporate that in each query for us would be a nightmare.  If it wasnt a constit code, we'd have to add it as an attribute.
  
  
• 
  
  We can also track/include/exclude memorial donors with 'memorial donor' as constituent code as per our procedures, memorial donors do not automatically carry over into our general solicitations. 
  
  
• 
  
  We may have a constituent that gave a memorial gift when board member passed away, using the constituent codes as we do allows us to easily know that this person is a prospective donor without having to run queries excluding memorial gifts. 
  
  

It works for us, I know it might not for others. 

We do track why/how record was acquired/source of record as an attribute with a table of choices.

We generally have a 'from' date for constituency codes and only use the 'to' field when appropriate for that code (no longer board member, staff member.)  We haven't really had issues with the dates as long as user is aware of how date can affect what is pulled.

Just another viewpoint...

Thanks JoAnn. I agree somethings work at one non-profit that doesn't fit another - sometimes you can't follow rules of others. Yes, that's what I meant about problems with using dates with constituency codes - I couldn't remember what the problem was in the past - when users ran reports they wouldn't take the constituency To and From dates into consideration and wondered why certain gifts didn't show up. Thanks again.

Julianne

JoAnn Strommen

Melissa Graves:

Gasping - and checking my pulse. :-0

If you are "checking this" as a monthly data management then don't you already have the query you say would be a nighmare?

If I included a donor in a non-donor mailing in the middle of a month because I had not done my audit - someone would have my head. Just my thought.

No, I don't really have the query that would be needed to filter for all our reports/mailings.  I can just query on gifts for the month and scan list to double check that constituency is correct. 

It's very apparent to me that as an org our needs are different from other national fund raising orgs. We don't have monthly mailings to donors/non-donors.  If that was part of our process, we would possibly need to adjust.

And the query would be a nightmare to keep current. Per our director and development dept , we want different code for memorial donors when family chooses our annual fund for the memorial. We need to be able to easily exclude them from future solicitation mailings to annual fund donors as we're not a multi-state org so avoid mailings to states requireing registration and keep to the philosophy that the donor give to/support their local YMCA vs. one across the country. 

Again, it's just what works for us.  [8-|]