Coding "Former" in Constituent Codes

Kathryn Hardi 2

I have only a few months experience in Raiser's Edge and I'm in the processing of doing a complete clean up of my organizations data and establishing the new polocies and procedures for how data is entereted going forward. RE has not been maximized, really its hardly been used, the past few years. Right now they don't even use constiuent codes. Right now I'm am proposing that we use:

Friend

Prospect

Staff

Board Member

Committee Member 


What are your opinions on having a "Former Board Member" "Committee Member" and "Former Staff" code in addition to using the constituent code dates. In my research into people's examples of their Orgs. some people have code former and some do not but I haven't understood the pros and cons of each.


Thank You!

JoAnn Strommen

You're exactly right - some org use "former" others don't.  There are some arguements for both.  We do not use former.  Instead we use the date from and date to show say when they served as a board member or were on staff.  If they go back on board or return as staff a second code is added.  This works for us and was how we started using RE I guess at advise of our BB consultant.  Don't know that I too knowledgeable about pros and cons.  Seems like what RE was designed to do, so we are using that way.


Have you searched the forums for posts and opinions on this?  Here's link to thread: https://community.blackbaud.com/forums/viewtopic/157/14436?post_id=46866#p46866

Just type in search 'constituent code' - you'll find posts about deleting, cleaning up, etc.  If you use gift constituency the codes should be looked at there too.

 

shani traum

We use former in some cases (I would like to use them in more). 


I find it useful when wanting to know at a single glance if someone is a current vs former volunteer leader (board members, trustee, etc) or if I want to filter on the same.  I don't want to have to decide on a query that will filter, based on relationship, who is a current VL.  Also, if I;m exporting info on constits and I pull Constit Code into the report, I want it to show what they are now, not what they were.


And my experience is that adding an end date to a Constit Code, drops it from reporting in some instances.  So former allows it to still show up.


So, I am "PRO" former.


Shani

Ryan Hyde

I'm also in the pro-"former" camp. You can use begin/end dates just fine, but that assumes that you know what the begin/end dates are. And if you don't know them for certain, should you guess? Is it worth asking your HR person exactly when a certain employee who has been here longer then you actually started, or when a former employee's actual last day on the job was? 


Also, I think using "former" really is easier for your users to understand at a glance. Sure, it's easy to check to see if the "date to" field is populated, but not everyone will remember to do that all the time, so anything you can do to reduce friction for everyone is, in my opinion, worth doing.

Jen Claudy

We use dates in most cases.  It is required that every record have at least one Constituent Code, of a subset of them (Board, Employee, Individual, etc.) and that is the Primary Constituent Code (which also automatically comes thru as the Gift Constituent Code...that can then be changed if necessary).  When someone rotates off the Board, that code is moved down so it's no longer the Primary, and then an End Date is added.  I like seeing the date ranges at a glance (in both RE:7 where it appears in red at the bottom of Bio1 and in RE:NXT where it's right at the top of the Record).  It gets confusing to use dates and former, because if you say someone worked at your org from Aug 2011 to Jan 2016, do you use those dates and say Employee-Former?  That could seem to indicate they were a former employee from those dates.


If you do decide to use Former, I would use Employee and Employee-Former rather than Former Employee, so that at least your codes sort in a useful manner.


I personally prefer using Attributes for something like Prospect, because that status can change more frequently (or be confusing if the same term is used to mean something else to your fundraisers).  At a former org, we had a list of about 5 different Prospect Codes that were in an Attribute Table, and they were updated according to recent giving history and/or Actions entered.  Changing it on the Const Code would have been more frustrating to me.  I tend to like the Const Codes to be somewhat static.  Plus, you can add a Comment to an Attribute, use the Date field to indicate the last time the Attribute was changed/updated, and put "see ConstNote" in the Comment if you need more space for further notes and don't want everyone constantly looking for an explanatory Note to an Attribute that may or may not be there.

Patti Hommes, bCRE-PRO

We use former as well. Initially we did not and just used the "Date to" field, but, as Shani mentioned,  this often drops that constituent from anaylitical reports depending on the date range. Using "Former Trustee" as an example, we have a "Trustee Type" attribute with "Former Trustee" as the description, and the attribute date serves as the "Date to" If we know the "Date from" we'll put the date range in the comments.

Faith Murray

We are going through a similar reorganization of our Constituent Codes. Before deciding on our final codes, we read Bill Connors' book, "Fundraising with the Raiser's Edge", visited similar orgs to ours that also use RE, and then sat down and discussed with our other staff what types of categories would be most important/useful to them. We eventually decided on a two-level system, with Primary Constituent Codes and Secondary ones. Our Primary codes are limited to 7 broad categories (including Foundations, Alumni, Business, Friend, etc.), which tells what kind of person they are. All records will have one of these seven codes as their Primary. We then have a list of Secondary codes including Board Member, Employee, Planned Giving Society, etc., which can be added as needed.


The reason we did this is to simplify reporting in RE's canned reports. On our Annual Report, only the Primary constituent code will display in the donor breakdown and charts. It becomes too complicated (and meaningless, to a panel of Board Members who only have 15 minutes to scan your report at a semi-annual meeting) to have a chart with more than about 10 main categories, especially when some of the donor categories may have given less than 1% of your total donations revenue (such as Former Employees). So, a former employee at our Org would become a Friend first, Former Employee second. By leaving these as Secondary Constituencies, we keep our annual reporting clean without losing valuable Constituency information on their individual records.

shani traum

I should have noted this in my earlier reply:


We track our to and from dates on the relationship tab.  So, if someone is a Trustee, they have a "relationship" to the Trustee org record that we created.  When someone becomes a Trustee we add the Constit Code of Volunteer Leader and then create a relationship with the start date and the relationship set as Leadership/Member.  When they leave, we change the Constit Code to Former Volunteer Leader and then on the relationship tab, we add the end date and change the relationship to Former Leadership/Former Member.


In addition to tracking the dates, it gives us a nice way to see and pull who is serving/served on the Board and associated committees. We just have to open the organization record call Trustees, Finance Committee, etc to see who the current and past members are.


 

Vicki Mayhew

I am firmly in the "Former" camp. I use the date to and from fields as well. And sometimes I remove their constituent code altogether and capture the information in Attributes.


For example, we may have an alumnus who is also on the Board of Trustees, is a parent, and the parent of a graduate. So he would be coded in this order:  Trustee, Parent, Alumnus, Alumni Parent.  When his son graduates, I remove his parent code. If he is not already coded as Alumni Parent, I add that code. If he stops serving as a Trustee, I remove that constituent code and on his attributes tab I list him as Former Board of Trustee and in the comments, I list the dates he served.


About the only time I mark a constituent code as "former" is for former students (who transferred or withdrew, but didn't graduate), former faculty (I especially want dates associated with these), and former grandparents. I try to avoid coding anyone as "Friend" unless I just can't find another appropriate code for them.


One reason I do it this way is so that I can create a query of several constituent codes, and don't have to worry about specifying the dates for each one. 

Bill Connors

Here's a fairly long and detailed answer to this question from me, in response to a similar question on a different site:  http://www.billconnors.com/media/Former%20Constituent%20Codes--post%20to%20fundsvcs.pdf