Don't have a membership module, but have one type of membership

Kate Hudson:
My org is considering getting the membership module but at this time it is out of our budget (we are a school so this is not our bread and butter). We have a Donor Circle at two levels, and others are added to this circle one a case by case basis. It is annual. I just started at this org and created a constituent code for it because it was not being tracked except through running gift reports, and those are not coming out correctly because of the special cases. Should I also create a Former/Lapsed Donor Circle Member constituent code? I can't think of another way to track those other than through an attribute or gift attribute. Ultimately, I'd like to be able to pull a list of everyone who has been in the circle, as well as a list of current Circle members while excluding the lapsed members, and the total raised from or pledged by members of this circle. I came from working in membership at an org with the membership module in RE so I'm not really sure what to do without it.

1. Using actions as memberships, basically creating some action types for your various levels, using the date fields available to record start/end, etc. This has the disadvantage that it can interfere with other action reporting unless you are careful.

2. Using relationships, where you create a record for the donor circle and a relationship types of the levels, and use date from/date to fields to track. You can set the relationship types for the various levels, etc. This has the disadvantage of not being easy to track on the transactional level - if someone switches back and forth between the lower and higher level and lapses frequently and whatnot, it gets very confusing without a bunch of duplication.

Or you can use constituent codes, which also have a date from/to.

Honesly, probably what I would do, in order to avoid being too clever, is use a combination of gift info and attributes. When you want a list, query for anyone who has given $X amount in (date range), or who has the attribute that you put on records that are added on a case by case basis. And on the case by case records, do an occasional audit query on the attribute date to make sure your comps aren't old.

Kate Hudson:
My org is considering getting the membership module but at this time it is out of our budget (we are a school so this is not our bread and butter). We have a Donor Circle at two levels, and others are added to this circle one a case by case basis. It is annual. I just started at this org and created a constituent code for it because it was not being tracked except through running gift reports, and those are not coming out correctly because of the special cases. Should I also create a Former/Lapsed Donor Circle Member constituent code? I can't think of another way to track those other than through an attribute or gift attribute. Ultimately, I'd like to be able to pull a list of everyone who has been in the circle, as well as a list of current Circle members while excluding the lapsed members, and the total raised from or pledged by members of this circle. I came from working in membership at an org with the membership module in RE so I'm not really sure what to do without it.

Kate,

A couple of thoughts... if you are talking about membership due to giving level that's a bit different than having a membership to a group/club within your org.  I was thinking about utilizing the donor category report but not sure how it would work with all your lapsed/former concerns.  Are you familiar with the donor category report?

If that doesn't have what you need, I would look at attribute or constituent code.  In using an attribute I would use a constituent one vs. gift as it sounds like their qualifying is based on more than one gift.  You might be able to get by with one attribute and just add each year in description or comment.  We do have a 'plaque recipient' type of group that I have to record based on giving level to our annual fund.  I do utiliize a gift attribute for it but it isn't the smoothest process easily pull report on.  I've figured out how to have it work for me. 

I try to keep our constituent code list to a minimum so that's why I would hesitate to add 2 codes to track this.  I do track members of our endowment club using constituent code, but it's a once you're in, you're in so I don't have to deal with lapsed/former.   One advantage of cc is that you can edit onscreen in batch where attribute you'll need to remember to update record separately.

Just saw your reply.  So, donors have to give to a special fund/appeal to be in Donor circle?  Or why the need for tagging gifts? 

Seems hard to be more helpful, not grasping your full structure for these gifts/report needs.  You may want to ask support for their input.

Kate Hudson:
JoAnn, Thank you so much for your reply. The gifts to this circle are to the Annual Fund. The Gift Subtype the org has been using is labeled Annual Fund as well. The reference code is the fiscal year. The gift code itself is the name of the Circle. I can query the gift code but it pulls each gift and makes duplicates in the results. We're on the same page about minimizing constituent codes - I think maybe a constituent attribute with the year may be better. I have never run a donor category report, but I will putz around with it! I realize none of these is a perfect solution but I plan to create a policies and procedures handbook for our department so they background and method will be in their no matter what we choose. I just want to give my department some options to see what they think will be best to use for the future when this Circle (hopefully) grows. I've just been made aware today of another issue I need to talk to support about (EE forcing dupes in RE when an alumni becomes an employee or employee is a parent that cannot be merged), so I'll bring it up with them.

I'd really do some evaluating of needed data entry. 

If your fund is annual fund, why double up by entering it again in gift sub-type?  Extra work and not intent of that field. 

You should be able to pull reports/lists based on gift date or fund, not entering by fiscal year in reference field.  Again not really what field designed for and it won't be available should you want to use it for something else. 

If data is entered correctly, I would think you should be able to create a query of donors who've given at your donor circle level for year XX, donors who've given at the level for year XY etc.  Then you can merge queries or use in LYBUNT reports etc.

While more info than needed can be good, sounds like your org has gotten in bad habit of entering same data more than once.  That's something I try to avoid as it just makes for a messy database. 

Just my opinion - we all need to do what works.