Constituent Codes at a Hospital

Courtney Klein 3

I am starting to look at cleaning up constituent codes because quite honestly, they are a mess. They have acquired over 40. This a fairly large hospital so I don't mind having 10+.

1. I am inpartial to using "donor" as a code but I am thinking it might be a good catch all if we don't have any info on the person or organization. Thoughts?

2. In general, what are some codes used by current hospitals?

3. How do people handle records who are the recipient of a tribute/IMO gift? Being a huge network, we probably have thousands of these records. Does it make sense to not put a constituent code here?


Codes I am considering in hierarchy order and I would be using to from dates.
Individual Records:

Board Member (then use relationship to distinguish which Board and which Hospital since we have many boards and Hospitals within the network

Physician

Employee

Patient

Donor

Prospect
Org Records:

Board Member (company they own/work for)

Vendor

Foundation

Corporate Foundation

Corporation/Business

Family Foundation

Government

Community Organization (clubs, groups, schools)


Thanks for any comments.


Courtney

Joshua Bekerman bCLO bCRE

Not sure about Org Records - Board Member.  That sounds more like a relationship type than a constituent code.  If you put that cons code on an org record that has multiple contacts how will you know which contact is the board member?  


A good guide for this is to think about your reporting needs.  For example, will you need reports that show giving grouped/totaled by these cons codes?  


One additional cons code for a hospital might be "guarantor" which might make sense if you want to track donor's who are not patients but responsible for one (instead of having to figure it out through relationships).  


I don't like the "Donor" code as that information can be determined by their gift information and constantly changes (depending on your definition of a donor).  I prefer "Individual" instead.  Also, if you use Donor, how would you code a patient, physician or employee that is also a donor?  Would they have two cons codes?  


"Prospect" also changes based on their giving and your definition.  If you use it be sure to clearly define when they are a prospect and when it should be updated/changed (are they still a prospect if an ask has been made?  Are they still a prospect if they told you that they are not interested in donating?).  I wouldn't use it, there are other codes in RE to track that they are a prospect.      


Josh

shani traum

Courtney Klein:

I am starting to look at cleaning up constituent codes because quite honestly, they are a mess. They have acquired over 40. This a fairly large hospital so I don't mind having 10+.

1. I am inpartial to using "donor" as a code but I am thinking it might be a good catch all if we don't have any info on the person or organization. Thoughts?

2. In general, what are some codes used by current hospitals?

3. How do people handle records who are the recipient of a tribute/IMO gift? Being a huge network, we probably have thousands of these records. Does it make sense to not put a constituent code here?


Codes I am considering in hierarchy order and I would be using to from dates.
Individual Records:

Board Member (then use relationship to distinguish which Board and which Hospital since we have many boards and Hospitals within the network

Physician

Employee

Patient

Donor

Prospect
Org Records:

Board Member (company they own/work for)

Vendor

Foundation

Corporate Foundation

Corporation/Business

Family Foundation

Government

Community Organization (clubs, groups, schools)


Thanks for any comments.


Courtney

40?!!  That's nothing!  I think we had 60+ before our clean up!


We have both a healthcare (long term and rehab) and housing components, so below are just the ones that apply to the healthcare side of things"


Volunteer Leader (These are Members of OUR Board of Directors, Committee members, Trustees for Life, etc)

Former Volunteer Leader (As this is an actual Constit code, not just signifying the end of their Volunteer role)

Patient

Family Member

Staff

Individual (ie, none of the above)

Organization (for non-profits)

Corporations (for profit)

Foundations

Board/Committee


The last one is for the record of the actual Board/Committee that someone might serve on. 


We track what Board/Committee a Volunteer Leader serves on through relationships, linked back to the Board/Committee record. So, let's say Jane Rogers is a Volunteer Leader.  We have set up a relationship between her and an Org record called "Board of Directors" (Leadership/member or once she done, Former Leadership/Former Member).  This allows us to have fewer Constit codes, while still being able to see the various leadership positions someone holds.  And allows up to see who the current and former members are on any specific Board/Committee.


We track Vendor under Attribute (a further definition of Corporation).


(Hope this made sense)


Shani

Courtney Klein 3

Joshua Bekerman bCRE:

Not sure about Org Records - Board Member.  That sounds more like a relationship type than a constituent code.  If you put that cons code on an org record that has multiple contacts how will you know which contact is the board member?  


A good guide for this is to think about your reporting needs.  For example, will you need reports that show giving grouped/totaled by these cons codes?  


One additional cons code for a hospital might be "guarantor" which might make sense if you want to track donor's who are not patients but responsible for one (instead of having to figure it out through relationships).  


I don't like the "Donor" code as that information can be determined by their gift information and constantly changes (depending on your definition of a donor).  I prefer "Individual" instead.  Also, if you use Donor, how would you code a patient, physician or employee that is also a donor?  Would they have two cons codes?  


"Prospect" also changes based on their giving and your definition.  If you use it be sure to clearly define when they are a prospect and when it should be updated/changed (are they still a prospect if an ask has been made?  Are they still a prospect if they told you that they are not interested in donating?).  I wouldn't use it, there are other codes in RE to track that they are a prospect.      


Josh

Josh - thanks for your responses. I agree about the Board Member on org records. It's how they set it up and I am not convinced. I was only thinking of using "donor" when we don't know anything else about them (i.e. we don't know that they are a patient, employee etc). But again that would mean upkeep for sure. I just don't know how to handle these people that donate but we don't know if they are one of those yet. We have a large grassroots program called Tackle Kids Cancer that is growing exponentially. Tons of people donate through this program who we don't have info on. Your suggestion is individual?


I would change prospect out once they committed. I understand what you are saying other codes. We do a good job of coding/adding proposals and such so maybe it isn't necessary.

Faith Murray

 

I believe the usual default for miscellaneous/unknown persons is "Friend", as opposed to Donor. Donor can be assessed via their Giving History, and if a Donor hasn't donated for 5+ years, are they still a donor?


If you wish to streamline your Const. codes furthur, one suggestion that came up on a different thread was to re-purpose the "Industry" field on Bio 2 to create a type of Const. code sub-category. So you could dub all Foundations as a "Foundation" Const. code, but then sub-categorize them as "Family Foundation" and "Corporate Foundation" under the Industry type. Same with Corporations/Businesses.


Bill Connors advised against using labels like "Major Gift Donor" as a Constituent Code, because that criteria changes frequently and can be hard to maintain accurately, in bulk, on a Constituent Code field. I assume the same principle would hold true for "Prospects". We currently mark Prospects using an Attribute in our system, since we don't have the Prospect module.


Other than that, I think your proposed list seems appropriate and functional.