finalizing constituent codes w/ few questions

Courtney Klein 3

We are narrowing down our constituent codes and I have a few other questions that my boss and I disagree on or just need confirmation that others are looking at these codes the same way.


1. My boss wants to add a constituent code called "Legacy Group". These are people who have committed to leaving us in their will or have passed and we received the distribution from their estate. I think a more suited place for this is addressee/salutation. When it comes to a donor's listing is addressee/salutation where most put this information?

2. From a Hospital perspective, do people code auxiliary members through constituent codes? We do not have the membership tab which might be a possibility or does using the Auxiliary record and relationships make most sense?

3. When an individual passes, their record is coded as deceased, an org record is created where the bequest sits. Other organizations use the constituent code bequest/trust for these?

5. Tribute records: do these need a constituent code? How do others handles these records constituent codes?


Again, I appreciate people's feedback!


Many thanks!

Courtney Klein

JoAnn Strommen

There are a lot of questions in your post that will to me depend on what/how you want to be able to pull data.  We do have a consituent code for our endowment/legacy members.  More detail about their 'membership' like bequest/outright gift/ etc is recorded in attributes.  We actually have a constit code of endowment prospect as that was why record was added to databse when we converted to RE.  We record how they wish to be listed as an add/sal on the addressee/saluation tab


At this point we don't use a code for estates/trusts.


We're not a hospital/membership org/tribute module user.  My 2 cents...


 

Christine Robertson

Courtney Klein:

We are narrowing down our constituent codes and I have a few other questions that my boss and I disagree on or just need confirmation that others are looking at these codes the same way.


1. My boss wants to add a constituent code called "Legacy Group". These are people who have committed to leaving us in their will or have passed and we received the distribution from their estate. I think a more suited place for this is addressee/salutation. When it comes to a donor's listing is addressee/salutation where most put this information?

2. From a Hospital perspective, do people code auxiliary members through constituent codes? We do not have the membership tab which might be a possibility or does using the Auxiliary record and relationships make most sense?

3. When an individual passes, their record is coded as deceased, an org record is created where the bequest sits. Other organizations use the constituent code bequest/trust for these?

5. Tribute records: do these need a constituent code? How do others handles these records constituent codes?


Again, I appreciate people's feedback!


Many thanks!

Courtney Klein

Like JoAnn said, a lot of this depends upon how you want to be able to pull the information back out of RE.  My thoughts below are based on my work with clients of ours who are also hospital foundations, so they may or may not fit your model.


If you need to be able to run a financial report on your Legacy group, then you really don't want to store it in Add/Sal because that will require you to set up queries prior to running any reports and it will be impossible to link the code directly to a gift.  Constituent codes can be linked directly to gifts (on tab 2 of the gift record).


The membership module would not be used to track Auxillary relationships even if you had it because it is geared more towards organizations that raise funds through donors purchasing memberships - ie a zoo membership where you get a discounted rate when you visit, etc.  It would be better to use an organizational relationship between the individual and the Auxillary so that you can add the start/end dates, information regarding position (president, etc.) and so that you have a way to see all connections at one time (so a major gifts officer could open the Auxillary record and gather a list of names to invite to a meeting, etc) without having to run reports.


Since estates/trusts are legal entities and are separate from the individual, we recommend that they have a separate organization record that is linked by relationship to the Individual record.  That way, tax receipts are sent correctly and you avoid the confusion of gifts made after a deceased date.


Personally, I think every record should have a constituent code.  I recommend that it be a required field so that no one can accidently leave it off of a record that should have it.  That said, depending on how you want to report on your constituent codes, you'll want to try to keep them very clean.  When constituents have multiple codes, it can become complicated and reports showing the percentages of gifts from each group are not the easiest to obtain.

Jen Claudy

After some trial and error, my preference for Donor Listing is as an Attribute.  This way, it doesn't get accidentally changed if someone adds or changes text in the fields composing the addressee/salutation.  Our default Listing is the same as Home Formal (i.e. Dr. & Mrs. Robert C. Hernandez) so I typically check the Edit box on that Addressee, copy the text, uncheck the box, and go paste the text in the Attribute.  (Once it became habit, it doesn't take nearly as long as it sounds.  And the initial setup I did with Export/Import processes, which I occasionally do again with a large number of new records.)  Keeping the Listing Text on an Attribute means this location is also available for Org Records, which don't have an Addr/Sal Tab.


However, most of this is your choice as an organization.  You need to set things up in a way that makes the most sense for you and for how you will be using the data.  I strongly recommend setting up and keeping several dummy records to test different things with, where you don't have to worry about restoring or messing up real records.  I have 4, an organization and then a couple each with their own record and a couple on one single record.  They have a Dummy Record Constituent Code that lets me exclude them from any real processes (queries, reports, etc) I may be doing.


As to your legacy group.  We do track this as a Constituent Code.  Two, actually.  One for the Legacy Society, meaning they've already made us aware of a bequest or other intention, and one for Legacy Prospect, meaning we've either started conversations, know of some interest, or want to approach the topic with that person.


In general, I use Constituent Codes for how the constituent is connected to my org, usually in a way that doesn't often change, and that can't very easily be pulled in some other way.  So I don't use a Const Code of "donor" because I can determine that from data on the Gift Tab (and this category could, in theory, change frequently...or more likely, the parameters for what types of donors we're pulling will change and this Const Code wouldn't be helpful).  Information that I want to have visible on Bio 1 (Const Codes appear at the bottom in red text) will go in as Const Codes.  Also information that I may want to use to quickly group records...often, that data is duplicated elsewhere.  For example, board members have a Constituent Code (set to Primary Constituency when an active board member), but the full details of their board service is on the Volunteer Tab.  I could pull a simple list of board members from either Const Code or Volunteer Tab, but it's generally faster from Const Code.  (And I want the Board Member status and associated dates to appear on Bio 1 for others to see.)


For Tribute Records, I assume you mean records you are adding for a person already deceased.  In the past, at my current org, they prefixed the Const ID with "Trib" to identify records added for the sole reason of storing data for a tribute when the new record is already deceased.  You could use a Constituent Code for this, which might make more sense...again, it depends on your org and how many of this situation you will find.  I would prefer a Const Code over a Const ID prefix.


When a constituent passes and leaves a gift for us in the estate, it depends.  If it's a one- (or maybe two-) time payout, I will change the Primary Const Code on the Ind record, and also update the Donor Listing in the Attribute.  If we expect to receive on-going payments or there is a surviving spouse (or some other reason to keep the Ind record as-is), then I will create a new record for the estate.  (And link them with a Relationship Record.)


For your auxillary situation, if you have the Volunteer Tab, this might work for you.  Otherwise, I suspect Relationship Records, as you mentioned, may be your best bet.


Ultimately, you'll need to think thru what will work best for how you need to be able to use/access/pull this data down the road.  In general, I try not to duplicate data unless it's necessary or helpful, and certainly only when there is low/no risk of that duplication causing issues (i.e. Solicit Codes...for that, there should be only one system).  A good Policies & Procedures Manual, or at least a collection of documentation, is a smart idea, because it will explain to others why your data is stored as it is...and how to use it if you're not available (when I worked in theater, we called that the "hit by a bus contingency plan").

Faith Murray

A Constituent Code makes perfect sense for a Legacy Group member, because Cons Codes are meant to convey how a donor is connected to your Org. A Legacy Group is as strong a connection as Board Member, Alumnus, or any of the others. That said, it doesn't have to be the Primary Cons Code. You can still designate these people as Alumnus or Friend first, and keep the Legacy Group as a secondary Cons Code.


We also use Attributes in conjunction with the Cons Code for our Planned Giving society. The Attribute gives more detail on the type of bequest expected, such as "Planned Giver - Will" or "Planned Giver - Annuity", along with any related comments.


To mimic Jen, we only create a new record for bequests/trusts if the trust is one that will continue to give for many years. A one or two time gift we simply post to the deceased person's record, and post it to our Bequests Fund.


As far as Tribute records, I can't give any advice on those, since we avoid them whenever possible. We try to reduce the number of dead constituents added to our database, and most of our memorials are one-time and only get one or two gifts associated with them. So we generally track these through a gift Attribute or Gift reference instead of using the Tribute function.

Laurie Nichols

Constituent Code.   That is definitely how i would do this.  We use address/salutation entries as a means to customize our mail merges.  ie; does the constituent prefer "Mrs. Parker" or "Sally Parker" etc.  Constituent Codes ( as i know them...) allow us to 'group' constituents into seperate catagories.  For example, a constituent might have 3 constituent codes entered for them because; 1. they are a 'Board Member'  and 2. they are also a local 'Business Owner' and 3. they volunteer at our shelter with a 'Church Group Volunteer'.   A majority of our Constituents have just 1 'designation'.  But it is very very helpful tobe able to pull data for specfic groups/types of records.

.....in my opinion!  :0)

Joy park

I would vote for Attributes as well, only because it can be tricky to remember ALL the instances that you need to account for Constituent Codes in Reports, Query, Export, etc.  There are SO many tools that depend on Const. Code and they aren't useful to you all of the time.  One size fits One!  


If you have more than one Const. Code, on say, Dr. Hernandez's record:  "Board Member" and "Legacy Giver", unless you very explicitly exclude types of Const. Code, you'll have RE doubling gifts, reporting twice the income, incorrectly calculating pledges, etc.  You'll be in serious trouble if said donor ever gives through their Family Foundation and needs to be Soft-Credited, as you will then have to remember SC on top of filtering Const. Code and then determine what the actual Giving History is!  Pray it's not a split gift!