I am the development assistant and database manager for raiser's edge at Cheshire Medical Center, NH. Lately, we just don't seem to be consitent with our coding policy and our reports don't reflect the correct totals and if someone has multiple codes then it creates issues with reports as well.  I must mention that last year our database completely crashed and and I was hired to re-build it from scratch purely by re-entering every gift over the past 5 years and re-entering lost codes. We have come a long way but I still run into many reporting, coding, and query problems with duplicate results and so on.

 I wanted to pose a question for anyone interested in commenting or suggesting  ways in which I can build or create a better system for constituency codes. Right now I have about 300 records with no codes. I am working off a query that shows me all records with blank codes and adding codes to each record as I go. If they have gift history, I code them as donor and in the attributes tab, specify for what type of fund or appeal. Some people who have no gift history have no code and I'm not sure what to do with them. Should I mark them inactive since there is no activity? Is there a general code that would be suggested? What about a constituent who is deceased and is an honor/memorial. Shoudl I code them as hon/mem? Lastly, what about the spouse who is the primary constituency and their spouse is deceased and they have no gift history?

Does anyone have any suggestions for consistency or best practices?

Thanks!

Martha D.

Have you done any searches for past posts on this topic.  This has been discussed a lot and it is always recommended you start there.

I do not recommend ever having a donor code.  There is no need for it because you can always query on whether someone is a donor based on the presence of gifts on the record.  Therefore I code all individuals with an individual code (unless you are a board member or former board member).  Try to think about your codes as a very basic description and preferably something that is not duplicative of something else on their record.  For example - why put an hon/memorial code on someone who is already coded as such on the honor memorial tab. It causes you to need to remember to do two things each time you need to add a tribute which increases the likelihood of an error.

I do not ever use the inactive checkbox simply due to the constituent having no activity.  Again search past postings on this topic and you will undoubtedly find my inactive records policy mentioned here in past postings.

One way you can search for previous posts related to constituency codes is by clicking the constituency code tag in the popular tags panel on the main forums page.

Hope this helps!

Martha,

With all due respect to Melissa who is very knowledgeable on RE, there are those of us who out there who do use a constit code of 'Donor.'  We do, as that is the primary relationship/reason many of our constituents are in RE. 

For those in RE, we hope to have a donors in the future we use a code of 'Prospective Donor'.  I would not mark them as inactive.  We do not have the module with the memorial/tribute info so I do have a constit code of 'Memorial/Honorarium Donor' for donors who've given to memorials but do not have any other relationship with the Y. 

I have the constit code displayed in the constituent window when I'm working in batch to enter gifts, so I can see anyone that needs to be changed from 'prospective donor' to 'donor.'   When I have a few spare minutes once a quarter I can run a query to make sure that no changes were missed.  Works for me.

To add the constit codes, I would work with queries and do global changes/add.  It would be much, much easier than opening 300 records.  Just be sure the query is pulling exactly the records you want. If you need the fund or appeal in the attribute (not sure why as you can filter on these - but I've seen that we each have unique needs for reports) you can also do this through global add.

Good luck.

I work with 5 hospitals, 28 clincis , etc. and we have a bit of a different system than some.

'Donor' we use for individual donors that may have been patients, etc. that have a 'general public' relationship with us. I would prefer this to say 'public' but management is more comfortable with donor as our general catch all. We do use Prospect for those that have never donated

We have a few different levels of employees (and also affiliates employees as constituency codes)

Board Members are a constituency code (encompassing all Boards but the specific Board detail is housed elsewhere)

Corporations, Foundations, Estates,Vendors, not for profits, matching gift orgs, Deceased etc. are all codes as well

Individual & Organization are constituent record types so i don't feel a need to categorize that way. I also don't feel a need to categorize what I consider gift types or appeals' as constituenct codes - i.e. Memorial Donors. I use solicit codes to use as an indication whether or not to mail to someone going forward.

We use the codes most in demographical/statistical reporting so you may want to base your constituency codes on how you want to report historically and going forward. Things like measuring employee participation, etc. BTW I use a deceased constituency code in addition to the deceased checkmark so that when these reports are run management can easily see what percentage of gifts are not renewable resources.

Hope this helps

I'd like to spart this conversation again, if others are willing...

I'd like to know how other organizations define the constituent code table.  We seem to have several definitions all working together, which creates confusion over what codes to add, when to add them, etc.:

1) "What is a person's broad relationship to our organization?"  For example, we have Trustee, Staff, Volunteer, and Vendor.  These are continuously updated.

2) "How did this person come to us?"  For example, we have Internet Client (for those who come to us via an online ticket purchase) and Collections (for those who donate an item to our museum collections).  My concern is this: How do we handle those who already live in our database, but later make an online ticket purchase? Do we add the code to THEIR record also?

3) "How can we further classify this organization for reporting purposes?"  For example, we have Corporate, Foundation, Government Agency, Donor-Advised Fund, Garden Club, Media, School, and Organization (aka, other non-profit)

4) "What campus is/was this constituent involved with?"  We have Atlanta History Center, Margaret Mitchell House and Cherokee Garden Library.  This definition is mostly outdated, now that we're merged and are one organization, and yet Atlanta History Center (the main campus) remains the "default" code, the one we add to pretty much every record.  Seems silly to me.  Doesn't really mean anything to us anymore.

5) We also have a special code for anyone who gives at a certain level.  This is for the unique purpose of integrating with Patron Edge.  This code enables a special annotation to pop up in PE when donors at that level walk in and make a transaction.

Curious what everyone's thoughts/suggestions might be for improvement.

Hi Julie, we use our Constituency Code very broadly also.  Individual, Corporation, Volunteer, Board Member, etc.  If someone happens to fit more than one category then it is added to their record in a hierarchy of sorts.  As far as the other questions, they seen like attributes that you would add to the record and not constituency codes.  I hope this helps.

Comments by #  

This is our also our main criteria 

1) "What is a person's broad relationship to our organization?"  For example, we have Trustee, Staff, Volunteer, and Vendor.  These are continuously updated.

We record this in an attribute - how the constit got into RE.  As to tracking people who purchase online ticket - not knowing your org - it doesn't seem that significant - will be used more and more where a donor to museum collection is something to track.

2) "How did this person come to us?"  For example, we have Internet Client (for those who come to us via an online ticket purchase) and Collections (for those who donate an item to our museum collections).  My concern is this: How do we handle those who already live in our database, but later make an online ticket purchase? Do we add the code to THEIR record also?

Most orgs I believe do track these types.  We have constit codes for this type of info

3) "How can we further classify this organization for reporting purposes?"  For example, we have Corporate, Foundation, Government Agency, Donor-Advised Fund, Garden Club, Media, School, and Organization (aka, other non-profit)

This could be constit code or attribute but if it's out of date and meaningless, I'd get rid of it

4) "What campus is/was this constituent involved with?"  We have Atlanta History Center, Margaret Mitchell House and Cherokee Garden Library.  This definition is mostly outdated, now that we're merged and are one organization, and yet Atlanta History Center (the main campus) remains the "default" code, the one we add to pretty much every record.  Seems silly to me.  Doesn't really mean anything to us anymore.

If you need this info as a constit code to work with PE, then leave it (I don't know anything about PE). 

5) We also have a special code for anyone who gives at a certain level.  This is for the unique purpose of integrating with Patron Edge.  This code enables a special annotation to pop up in PE when donors at that level walk in and make a transaction.

Have you purchased/read Bill Connors book "Fundraising with The Raiser's Edge: A Non-Technical Guide" a lot of what you are asking can be answered in there. Bill has a great fruit salad reference that makes deciding what should be a constituent code make so much sense.

All of the above are options any organization can choose - there is no real one right way. Some are easier to manage and others are a necessary nightmare (like your donor code for PE - hate it but can see it being helpful but does it really have to be a constituent code?).

I have an attribute of Source that I use to determine where a constituent first came from - that is important especially if they were in RE before they started giving, etc. but subequent interacions are most likely coded elsewhere (and if not, should be). If the gifts they gave are coded Internet and/or Collections why repeat this as a constituent code? That is silly, IMHO.

If your current procedures are not documented or consistent, I'd just start by documenting them and see what does not work. (and read Bill's Book!)

Hi Julie,

We use constituency codes to define why someone is in our database (with the execption of donor) e.g. board member, committee member, volunteer, staff, professional advisor, media, foundation etc.

We use attributes for how a person came to hear about us.

To further define a board member who serves on committees we give them the BOAR and say INVST (Investment Committee), we define our Professional Advisors (FINA) into levels based on referrals (sending us donors who establish funds), we also categorize them by the type of Professional Advisor - CPA, Attorney, Financial Planner, Banker etc.

I really can't help with #4  - maybe - we track what county within the state that a person is associated with by address, if someone is from outside Maine we use the Region which we have re-labled County Interest.

We use a DONR1 code for all donors of $250,000 lifetime giving. We established a DONR2 and DONR3 code but found that we can query on those levels easily enough. The DONR1 folks along with our charter and premium funds (1 mm to 3 mm and 3+ respectivley) have special services. The Charter and Premium levels may or may not have the DONR1 code, but have their own constituency codes.

We have a lot of constituency codes and attributes, but I don't think we are over burdened.

Hope this helps.

Karen

I just had a post about constituency codes.

I'd like to report that we are using the consituent code to define the relationship between the constituent and the organization. We are using the attributes to further break down the relationship if necessary. For example, Employee as the constituent code and attribute will describe what dept., i.e Linden Oaks Hospital, Heart Hospital, etc.

LaShawnda -

 So why did you choose to do this as a constituent code vs. just building a relationship between the individual and the organization? 

• Couldn't you just as easily find all the employees at the Linden Oaks Hospital by querying on the relationship? 
• Are you only recording this as a constituency code and not as a relationship?
• If you're doing it both ways, then how do you make sure that the data is being maintained in both locations?

I'm actually doing it both ways...I decided to do it both ways because of the different levels of experience with Raiser's Edge. This is a very small foundation and not everyone knows how to use Raiser's Edge (another thing we're working on, training) the ED wants to be able to open a record and see if the constituent is an employee, board member, etc and doesn't want to look at the different tabs (her choice). But when I am asked how many employees gave from one location verses another I can easily break that down for her.

LaShawnda - when someone wants that - I simply create a business rule that pops up when you open a record like this and then you do not have to do double entry. Business Rules are the way to go.

I like the idea of using a business rule. Thanks Melissa!