FundSvcs Community

 View Only
  • 1.  When (or when not) to Add a New Constituent

    Posted 04-23-2025 10:55 AM

    Greetings, Everyone!

    As we have been pushing forward into our database conversion, we have been discussing when (or when not) to add a new constituent.  Some examples include:

    • Someone outside of our database volunteers as as part of our volunteer program.
    • Someone attends an event as a guest of a constituent

    I know that, ultimately, we need to decide what actions are valuable to us and detail those as part of a policy.  I'm curious, though, if anyone else has detailed this.  I would be grateful for a template to move our own efforts forward.  Also, if anyone would like to share your thoughts in the thread, I would be grateful for your thought leadership.

    Cheers!



    ------------------------------
    Michael Adzovic
    Northern Illinois University Foundation
    madzovic@niu.edu
    ------------------------------


  • 2.  RE: When (or when not) to Add a New Constituent

    Posted 04-24-2025 01:54 PM

    Hi Michael,

    We have standardized a ton of stuff, but not specifically this, because it can be a judgment call in some cases. We have no limit on the number of constituents we can store, so that isn't a concern. We use BBCRM, and I could be wrong about this, but I'm pretty sure we moved away from the OOB event functionality where an event guest could be just a name and not an actual constituent. I think it is pretty straightforward to say it is necessary to add a constituent record when they have some type of engagement or potential engagement with your institution – alumni, students, parents of students, donors, event attendees and guests, people who have opted into campus mailings, people who have bought tickets to campus performances, etc. If you are tracking volunteers in your CRM or even if you are simply seeing that as some type of engagement by a potential donor, I think it is wise to add those folks.

     

    For us, the judgment call is usually around adding relatives for informational purposes. When we converted from a home-grown system to BBCRM, we had to make all relatives in the old system into constituents in the new one. This meant a TON of records with nothing but a name and a relationship to another constituent – no contact info or giving info. This also created a bunch of dupes, because we couldn't catch if some constituents were actually related to the same people. It has taken a good long while to resolve the dupes, and now many of these relation-only records have been fleshed out with contact info and many have become donors too. A couple of examples we would question at this point would be: should we add very young children or deceased people as constituents just so we capture those relationships? We do, if there is a specific need, especially coming from our Principal Giving team. However, if there is another place to store this info to facilitate donor relations, you might consider doing that instead, when the related constituent may not ever give or have other engagement.

     

    We also get requests to add a record in anticipation of a gift or other engagement. We have a report that flags these records if they have been in our system for more than a year with nothing else added to the constituent. At that point we could decide to delete them. The trickiest part was to come up with the report logic showing there is nothing else on the record, because there are SO MANY places information is stored. Each constituent is manually reviewed for anything the report might have missed before a deletion occurs.

     

    Not sure if any of this applies to your situation, but I hope it is helpful!

    Kelli

     

    Kelli Crispin

    Senior Business Analyst/Quality Assurance Specialist

    she/they

     

    The University of North Carolina at Chapel Hill 

    Office of University Development

     

    E  kelli.crispin@unc.edu

     

    signature_3134537346

     

    GIVE.UNC.EDU

     

     






  • 3.  RE: When (or when not) to Add a New Constituent

    Posted 05-01-2025 11:09 AM

    This is always an interesting topic @Michael Adzovic.  I have always tried to make these decisions simple; we create a new constituent when two criteria are met:

    1. We have a need to record a relationship with the organization or more information than can be recorded on a non-constituent record.
    2. We have all of the data needed to create the record.  At my org, we require at least one method of communication as well as a name fields. At least some way to determine if this record may be a duplicate somewhere down the line.  It seems obvious to say, but you would be surprised how often people ask for records to be created without the minimum amount of information.

    Going back to number 1, this is where the decisions need to be made.  For instance, attending as a guest would not be enough to warrant a constituent record, as there is no shown relationship with the organization.  Attending as a guest of a constituent only shows a relationship to that entity.  My organization defines a relationship by making a gift or being a prospect, having a defined relationship with the organization (i.e. Board, Employee, etc.), or having a defined action outside of a relationship with another constituent.  For instance, if we have two married individuals who have different constituencies with the organization.  A lot of these things depend on the business rules of your organization.



    ------------------------------
    Dariel Dixon
    Chautauqua Institution
    ddixon@chq.org
    ------------------------------



  • 4.  RE: When (or when not) to Add a New Constituent

    Posted 05-01-2025 01:54 PM
    Edited by Alan Hejnal 05-01-2025 01:56 PM

    Such a fun topic!

    Dariel's criteria are clearly stated and readily applied, and very close to our criteria.  The only difference is that, while we would absolutely like to have contact information (and as many contact points as possible), our criteria focus on being able to differential this John Smith from all the other John Smiths in the world.  Contact data is the usual way to do that, but sometimes we will, under the right circumstances, satisfy the requirement with some other triangulating data point, like this is the John Smith is a business associate of Mary Jones, or the John Smith who is the recipient of the Galactic Prize for Extreme Cleverness, etc.  Sometimes all we know is that this is the John Smith who was referenced in a Benevity distribution and whose zip code is 12345.  Sigh.

    We're now in the process of implementing a new CRM whose architecture does not appear to allow the same structure as our legacy system, namely, that a spouse or child or guest or other relationship can be specified (ideally) as a link to another record or (alternatively) as a free text field where we type in the other person's name.  Our initial design in the new CRM is to set up a second person record type, tentatively called "Non-Constituent Person," that would be designed for a stripped-down record that would have to be linked in one of a limited set of contexts, such as the child of a full Person constituent or a guest at an event where we don't have additional information about (or interest in).  The design also includes the requirement that, if we do later develop additional interest (and have additional information to record), there will be an easy process to convert the Non-Constituent Person record to a Person record.  And the same structure would apply to a Non-Constituent Organization, which we might use to list an employer in which we don't otherwise have an interest, etc.

    How well will that work?  No idea.  It seems to have vanished into some downstream eddy of the implementation plan.  I'm casting a line from time to time to try to pull it back out of the depths before we float past it....



    ------------------------------
    Alan S. Hejnal (he/him)
    Smithsonian Institution
    Washington DC
    hejnala@si.edu
    ------------------------------