nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Grouping constituents for gift reporting and prospect management

Katie Kelly

Does anyone have any suggestions for how to group constituents so that when we're querying/reporting, the group could be looked at as one donor/prospect?

To further explain, we might have five constituents: 1. Mr. John Smith, 2. Mrs. Jane Smith, 3. John and Jane Smith Enterprises, 4. Smith Family Foundation, 5. 1000001 Canada Inc.

When someone solicits John or Jane, they might make the donation via any of the constituents. We soft credit John and Jane for gifts made through their companies/family foundation.

When we want to find all donors who have given a certain amount in a certain time frame, we want to be able to include gifts from all 5 constituents, but we only want to see one result (i.e. John Smith) with the total of giving from his "group".

Similarly, when we're looking at a development officer's prospect pool, all 5 constituents will be assigned to the same development officer, but we want to be able to group these prospects so we can consider it as one relationship being managed and all asks being coordinated for the "group".

Has anyone encountered a similar problem or have any suggestions for how to create these groups? Thanks!

Find more posts tagged with

RaisersEdge7 Databaseview

Comments

James Andrews

My first thought would be to create a record for the group, and use relationships.

Katie Kelly

Thanks James. That's interesting...could we then exclude constituents from queries based on relationships?

James Andrews

Sure! I would set up a specific type (or types) of relationship in order to easily query for these.

Tom Klimchak

We've done this sort of thing with attributes.

So in your scenario of 5 different records we'd take the PRIMARY one (let's say #1) and we'd put his RE ID into an Attribute called "Primary Record of" on the other four records. So we could query on every record with a "Primary Record Of" = blank.

And then, yes, we assign each person to the same Development Officer...

James Andrews

That's also a good idea. Did you know that you can make an attribute that links to a constituent record? That could work.

Julia Kalinkina

This is exactly the issue we tried to solve several years ago.

We have two attributes:

1. Donor Count Type = Primary, Secondary, or blank. Blank helps to distinguish those ones we haven't looked into yet.

2. Primary Donor = constituent's record of the primary one (same for the whole group).

Additionally, at least primary record should be soft credited for all the gifts (meaning it should have relationship to every record in the group), plus they should be assigned to the same person, plus should have the same Donor Type attribute (giving level).

Works for us - now fundraisers can look just at primary and be sure they are seeing the full giving history, we can count these groups as one donor in our reports, we can export lists with just primary donors etc. Involves lots of maintenance though - I even had to develop some Python script that completes the exported from RE data with Primary donor ID (in RE you can export name from attribute, but not ID ?‍♀️) via SKY API, then parses the data and separates incorrect records into several files with different "diagnosis" - i.e., secondary without primary, different donor types, not soft credited gifts, etc. Sometimes I really hate it as I now ALWAYS have to remember to include these two attributes into export and sort by them to see the groups correctly.

Hope it helps, let me know if any questions - happy to share what we have!

Katie Kelly

Thanks for all the advice everyone - super helpful (although Julia you lost me a little on the Python script and SKY API...not my strong suit!).

Two things are concerning me before we move ahead:

1. the level of maintenance involved

2. our soft crediting has historically been inconsistent so I dont know how effective reports will be unless me go back and fix the soft credit history. We're probably talking about a total of around 1,000 constituents that need to be put into groups so I'm wondering if it's feasible to go back and fix the soft credits.

Julie or Tom, do you have any procedures written out that you might be willing to share?

Thank you all - I've been puzzling over this for weeks and getting nowhere!

Julia Kalinkina

I think there is no other way - you have to invest a lot of time in the beginning anyway. I spent quite much time grouping them together (starting with major donors, then moving on to lower level ones), but after that it's just weekly/fortnightly check ups with some tweaks. For soft crediting, you will need to come up with a set of rules for each case - e.g., always soft credit spouse, always soft credit joint record and both spouses, do not soft credit contact person for organisation's gift, leave previously soft credited gifts in place when a couple divorces, etc. Unfortunately, we don't have a written procedure at the moment - just a memory dump in Excel spreadsheet (can send it to you if you wish).

It is a very hard task, really. We were also looking into Salesforce and their concept of households, but it is pretty much the same. It's a pity RE doesn't have any built in functionality for this.

Carlene Johnson

but after that it's just weekly/fortnightly check ups with some tweaks.

Julia Kalinkina‍ I just want you to know how much I appreciate you for using the term "fortnightly" instead of bi-weekly. ? I had a series of reports set up in Queue called "Fortnightly Reports" and some of my colleagues were confused by the terminology!