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.

James Andrews

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.

A couple kludgy workarounds for this - both have the disadvantage that you can't link to gifts.

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

James Andrews:
A couple kludgy workarounds for this - both have the disadvantage that you can't link to gifts.

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.

Thank you! I do know now that gift codes are being used to tag each gift made for or towards this membership, but it is not the best way to pull it. I really appreciate your suggestions.

JoAnn Strommen

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 Strommen:

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.

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.

JoAnn Strommen

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.

Melissa Graves 3

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.

Kate - I am in the mind of Joann. Keep your coding to a minimum. Gift subtype functions as a financial extension of fund so unless using it this way, avoid using it altogether, IMHO. Can you explain what your exceptions are? Can you consider using the "other" gift type to put in gifts that will put these constituents into the giving category you want them in? This is commonly what "other" gifts are used for (type=other not pay method=other). Unless you are using other for something very specific this often works. If not, then I would still go back to using constituent queries based on total giving in the year and only add a special gift attribute for the few (hopefully few) exceptions. You can then create a query of total giving greater than or equal to X OR attribute = Y. This will keep your data entry to a minimum since you're already adding the gifts and hopefully have to rarely add attributes and your query will be correct and up to date every time you run it. Not constantly something you have to monitor.

Kate Hudson

JoAnn Strommen:

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.

"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." I agree! I am hoping at some point I am able to gain some control and can work to change these policies, but I worry about the data that is already there. I may not be able to. This issue is really indicative of a bigger policy and procedures issue. I've only been here about a month, not including our summer vacation, so I feel I'm in a precarious place. Creating a handbook for my department is a dream goal for this year. I just may need to use a constituent attribute as a patchwork fix in the mean time. Essentially, if I pull a query or report based on gifts, not everyone in the circle will show up, because what I *think* happened is a couple of people were added even without their gifts matching the level, on an ad hoc basis. However, I did pull a donor type list and I believe that works.

JoAnn Strommen

Kate Hudson:
"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." I agree! I am hoping at some point I am able to gain some control and can work to change these policies, but I worry about the data that is already there. I may not be able to. This issue is really indicative of a bigger policy and procedures issue. I've only been here about a month, not including our summer vacation, so I feel I'm in a precarious place. Creating a handbook for my department is a dream goal for this year. I just may need to use a constituent attribute as a patchwork fix in the mean time. Essentially, if I pull a query or report based on gifts, not everyone in the circle will show up, because what I *think* happened is a couple of people were added even without their gifts matching the level, on an ad hoc basis. However, I did pull a donor type list and I believe that works.

Kate, Don't stress out about the old gifts.  I would just work on a plan for going forward first. 

And yes you'll need to work on a policy/procedure document but don't rush it either.  Give yourself to get your feet on the ground with the org.

I have a couple of those "exceptions" for our lists too (two sister businesses each pay half of gift for the level).  We all have something like that.  You'll just need to figure out who they are and make yourself some notes so that when reports are run you can be sure they are added if they don't pull.

Don't give up.  [;)]