Time to play "Attribute or Constituent Code?"

Options
We have other constituencies in RE other than donors, so over the years, our list of Constituent Codes has grown, a lot. (For example, our Faith Community Outreach team keeps track of their constituents, which include some donors and donor churches, but also several other groups of folks.)



We are looking to use RE as the primary CRM tool, and this means that we'll eventually take on even more groups. We want to narrow down our Constituent Code table so it's easy to use for segmenting communications and reports. Beyond that, is more detailed membership better tracked in Attributes?



We're thinking Constituent Codes equal Individual and Donor, then Attributes would show this person as a Legacy Society member, Board member, specific donor level, member of our Wellness facility, etc. Before making any sweeping changes, I need to make sure this is the most efficient way to go.



How do you segment?

Comments

  • I just went through that in a database I inherited that was a result of merging two separate RE databases. I pared down the Constituent Codes from over 100 to just under 20, and used Attributes to further identify the constituent. One example is Constituent Code = Trustee and Attribute "Trustee Type" is one of Trustee Emiritus, Honorary Trustee, Ex-Officio etc. (these were all formerly Constituent Codes)
  • Hi Jennifer,

    We use attributes to track a segmented giving society within our agency.  For example we use the following:

    Attribute Category: Name of Giving Society

    Description (Table): Fiscal Year they were a member

    Date: Date you added them to the giving society

    Comments: Development Staff member who added them to the giving society

    This Attribute is extremely helpful in helping us query upon the giving society and each specific fiscal year they were a member which all enable accurate retention and giving reports to be generated. 

    Hope this helps.

    Barb
  • Jennifer –

    I’d suggest the following to consider (as an alternative to either an attribute or constituent code):

    ·         Can you create your segmentations by using logic that already exists on the record?

    o   Ex: If your donor level is based on their giving history (gave $xxx dollars in the past xx years) you can get this group by criteria in a query.

    o   There’s really no value add to creating a separate coding system for this, and a separate coding system must be maintained.  Over time, they may fall ‘out’ of the code definition and you then need to remove the code. And it’s often not possible to answer ‘who was in this donor level 10 years ago’ with a simple coding system.

    ·         For membership in groups or boards, you can create a ‘fake’ organization record for the group and then add members using an individual relationship.

    o   Ex: We have an organization record for each of our boards, and maintain membership by creating individual relationships to the organization record.

    o   You can record a lot of information about the ‘membership’ on the relationship, and track multiple times when someone might be on or off the group.

    o   You can then create a query to get members of the group (everyone who has a relationship to ORG record and has the relationship type of ‘Member-Current’ (or however you set it up).  And you can easily find out who was formerly or is currently in the group.

    So in general, I think it’s better to try to use your data to create your groupings when possible. Constituent codes are best left high-level and as simple as possible. Additional codes (either extra constituent codes or attributes) are ‘tempting’ as they are seemingly easier to work with and use in queries.  But additional coding on records always requires review and maintenance, and coding doesn’t work that well if you have situations where people will fall in and out of your groupings over time.  So it may depend on the specific groups/segments you’re trying to capture and how long-term you need your data to be.

    Gina Gerhard

    Business Systems Analyst

    New Hampshire Charitable Foundation


  • I went through this when I started.  I inherited a database that had over 50 constituent codes.  My belief is that constituent codes show how a person is generally associated with your organization.  We use attributes to subdivide those generals into more specific details (e.g. constituent code = Parent; attribute = Current Undergrad Parent, Former Undergrad Parent, etc. or constituent Code = Alumni; attribute = Graduate School Graduate, Undergraduate Graduate, Withdrawn Alumni [12 units or more] etc.)  Under Attributes, we have Type of Individual and Type of Organization. 
  • In keeping with the idea that the Constituent Code tells us how the record is related to our organization, we use a handful of primary constituent codes which are in ALL CAPS so they're easy to spot. The primary code is listed first and then their are some secondary codes not capitalized which help further define the connection i.e.

    ALUMNUS

    Alumni Associate

    Alumni Bachelor



    FRIEND

    Current Staff



    We also use quite a few attributes, and all of these are useful for querying and sorting the data.

    I really LIKE Gina's suggestion (and I am totally stealing it) of creating "fake organizations" to help keep track of various boards, advisory groups and other groupings of folks.



    Roger
  • Question for Roger....

    Not knowing your heirarchy, do you have 2 constituent codes for Alumnus, one capitalized and one not capitalized? In our case the Heirarchy is Trustee, Former Trustee, Alumni..... So in your scenario Trustee would always be in caps, but Alumni would have to 2 separate codes - one in caps and one in lower case.  If they were a Trustee and an Alum, Trustee would be in caps and Alum would not, but if they were just an Alum, that would be in caps?
  • JoAnn Strommen
    JoAnn Strommen ✭✭✭✭✭
    Ancient Membership Facilitator 4 Name Dropper Photogenic
    It is really nice to have a manageable size list of constituent codes so having a plan and even re-evaluating it every few years is so key.   When the list gets too big it really loses value. As others mentioned, we also have purpose for constituent codes of "why is this person/business in our database?"  They have given great ideas/suggestions.  



    Another 2 cents to think about: this is just my view and I know the constituent code "individual" is used by many orgs.  We do not use it as the fact that they are an 'individual' is already part of record as key indicator.  Why duplicate data?  And, the record is not in database because they are an individual - so we choose one of 3-4 other codes.  We made this decision at conversion of our data to RE years ago actually at suggestion of BB staff we were working with.  We've been quite happy with that decision.
  • Like many others that commented, we try to limit the use of consituency codes but we do want the codes to be sufficient enough to describe the relationship the individual has with us.  Likewise, our development officers like to see important relationships right away on PAGE ONE (that is the Bio 1 screen).    Our constituency codes therefore include such things as:  Board Member, Legacy Member, Hospital Executive, Giving Club Membership.  However, we only include these codes on the record when the individaul is active and rather than end dating, we remove the constituency code when it no longer applies.  We keep the historical information in attributes and we use attributes to further distinguish the relationship:  ie: specific board membership with dates to/from in comments, specific legacy society membership, various committee memberships with dates to/from in comments etc.



     
  • JoAnn Strommen:

    It is really nice to have a manageable size list of constituent codes so having a plan and even re-evaluating it every few years is so key.   When the list gets too big it really loses value. As others mentioned, we also have purpose for constituent codes of "why is this person/business in our database?"  They have given great ideas/suggestions.  



    Another 2 cents to think about: this is just my view and I know the constituent code "individual" is used by many orgs.  We do not use it as the fact that they are an 'individual' is already part of record as key indicator.  Why duplicate data?  And, the record is not in database because they are an individual - so we choose one of 3-4 other codes.  We made this decision at conversion of our data to RE years ago actually at suggestion of BB staff we were working with.  We've been quite happy with that decision.

    JoAnn, I also hate the use of "individual" as constituent code, but have a system that has been using that for years. My dilemma is not really knowing what codes to use, especially if I don't know the constituent. I also hate the code "donor" as that can change often. What are the 3-4 codes you use? Prospect?

  • I will also suggest that you look at how RE handles constituent codes versus attributes in the database.  For one, I find it easier to use certain mail functions with constituent codes rather than attributes. 



    I also find the use of "individual" to be redundant, but I find it useful as we export constiuent codes when reviewing reports and other data and it makes it easy to have individual, corp, foundation, etc all in the same place.  I also use constituencies on the gifts for this same purpose.  A board member's annual gifts may be coded board, but a small gift in honor of someone is coded individual.  Youve gotta have individual onthe record to do that.
  • Using a Constituent Code will let you easily run many canned reports by constituency for analysis of who is giving at what levels.  Attributes don't have that easy ability.  Constituent Codes will also let you track beginning and ending dates which Attributes can't do.  Constituent Codes will automatically adjust heirarchy based on start and end dates (this is a double-edged sword).  Mail setups can be easily filtered to include only selected Constituent Codes (I wish you could easily filter to EXCLUDE selected Codes, like "Board Member," which is a request at the Discovery suggestions site).
  • RE Mail also allows you to easily include/exclude constituents from a mailing based on attributes. Although I agree thevworst part about attributes is that there are no to/from dates. 



     
  • I have had to do this clean in several times.  And let me say, walking in behind someone else's set up that is not explained and is not self-explanatory -- ugh.  I would high suggest staying away for the Constit Codes called Individual and Organization, that is the equivalent of not using the Constit Code field at all, and is redundant.

    One of my pet peeves is that the Constit Code does not have a 2ndary or sub code.

    The Constituent Code should really the the relationship/affilation that record/donor/constituent has with your organization.  Alumni, Board of Directors, Parents, Grandparents, Foundations, Business/Corporation, Educational Institution, Friend, Friend-Contact for Org



    Because sometimes you need further explanation/filtering how their affilation I keep an Attribute with a drop-down that has those sub-categories like: This committee or That Society or Some Association or Board Pres Personal Friends/Colleagues.  Then when you need to query or report you can go big picture or dial down a little more specific if needed.  Has worked fabulously.



    And as someone else mentioned the canned reporting works based Constituent not on Attributes the reporting is clean and quick when you need it to be something you don't want to export and re-work outside of RE.
  • Just a comment on the remark about constituent codes not having a 'sub-code'.
    • It's my understanding that's the distinction that RE offers between the 'primary' constituency code and additional constituency codes.  The constituent code in the top position is considered by the system the primary one.
    • In query and export they provide the ability to pull on ONLY the primary code, or all the codes.  So in a sense, that serves as a sub-coding system.
    • But I don't think in the filter tabs in mail and reports they offer this distinction?
    Is that other's understanding of how this works?

Categories