When I worked at a K12, constituent codes became my nemesis. Due to the nature of relationships, one constituent could easily be a staff member, an alum, an alum parent and a current grandparent. All four represent significant relationships to the school and all four represent streams of revenue that my (former) employer wanted to track. As a development team, we worked out a hierarchy and reported based upon that, but the resolution never quite accounted for the fact that this one individual really did fall into multiple buckets.
Since that time, I’ve become a proponent of limiting constituent codes. If it’s at all possible, I’d prefer records to only have one code. But, when that isn’t possible, I want the constituent codes to really matter.
So, in no particular order, here are my guidelines for constituent codes:
1. They are meaningful. “Donor” is a perfect example of this. It leaves more questions than answers. When was the gift made? What is the constituent’s relationship to your organization? Why use this code when you can tell that a constituent gave easily using the gift tab?
2. They relate to revenue streams. Does your organization report on board, alum, staff or volunteer giving? Then those should likely be constituent codes.
3. They are long term. I’m not a fan of codes that I have to continually change. It’s one thing to enter new gifts, relationships, event participations, volunteer roles, etc. It’s another thing to continually update that in more than one place.
4. They have a hierarchy. If I am an employee, then there is no reason for me to also be a friend of the organization. You’d track my giving as an employee. If I must have two or more codes, then you need a system as to which is most relevant.
I know that there are many points of view on this topic and I’d love to hear yours. What do you think is important in regards to constituent codes in Raiser’s Edge?
Bình luận