Including Gift info in Participant export

Daniel Noga 2 · June 2016

Hey everyone,

Our museum has a standing Participant export based on a query of "Event ID <ask>," that our events people run in order to produce registration lists for event check-in. They are now asking if I can modify the export to show who actually paid for the tickets vs. who is a guest. I'm having trouble finding a direct approach such as pulling info about the gift itself. The solution I'm leaning towards is simply adding a column of "Guest of," and telling them that the rows with an empty cell in that column are the primary registrants (either the one who paid if it was a paid event, or the membership holder if it's a free-for-members event). I don't like this as much because A) It looks pretty "workaround-y" and I want them to be confident in what they are looking at, and

It won't readily make sense to someone looking at such a sheet for the first time ever, and that could easily happen--and, again, I want them to be confident in what they are looking at.

If there is a good way to do this from within a Participant export, I am all ears, but am open to using a different kind of export if it would make this easier.

shani traum · June 2016

We use Participant Status to note paid and not paid.

Status options used are Not Paid, Paid, Guest, Complimentary (and a few variations)

Daniel Noga 2 · June 2016

shani traum:

We use Participant Status to note paid and not paid.

Status options used are Not Paid, Paid, Guest, Complimentary (and a few variations)

This could be a good solution for us, but I would rather resolve this by editing the export or setting up a new one (maybe an Event-based one) rather than changing our procedures for processing registrations. It's just an easier change to make organizationally.

shani traum · June 2016

Gotha - how about this?

I was looking at our reports...it looks like we pull in "registration fees gifts"...Gift Amount and Gift Type. I pulled in a couple of each.

What I get is the participant name and associated gifts:

Name Gift Amount Gift Type Gift Amount Gift Type

John Cohen 50.00 Pledge 50.00 Pay Cash

Jane Levine 100.00 Cash

Dan Swartz

John made a pledge and paid it off

Jane paid straight out

Dan is a guest.

Does this work?

Daniel Noga 2 · June 2016

shani traum:

Gotha - how about this?

I was looking at our reports...it looks like we pull in "registration fees gifts"...Gift Amount and Gift Type. I pulled in a couple of each.

What I get is the participant name and associated gifts:

Name Gift Amount Gift Type Gift Amount Gift Type

John Cohen 50.00 Pledge 50.00 Pay Cash

Jane Levine 100.00 Cash

Dan Swartz

John made a pledge and paid it off

Jane paid straight out

Dan is a guest.

Does this work?

It may. I had looked at that node in export, but I wasn't sure if it would be pulling data directly from the Gift record, or if its output is based on what is found in the Registration Fees tab (which may not be what we are looking for, since the listings in this tab may or may not reflect gifts given by that same person--it could be someone else's gift applied to the registration, correct?

But it looks like what you pull does come from the Gift record if it's able to list the gift type. Does it credit the full amount to the person who actually has the gift on their record?

Ryan Hyde · June 2016

Perhaps you could includ "Participant Type," which would indicate if the person is a Sponsor, Registrant, or Guest. Then you could also include "sponsored by" and "guest of" fields, so you see who paid for them if they did not pay themselves.

Are they looking to see who still needs to pay for their tickets? Or are they just interested in seeing the general level of commitment to the event based on who paid for whom?

Daniel Noga 2 · June 2016

Ryan Hyde:

Perhaps you could includ "Participant Type," which would indicate if the person is a Sponsor, Registrant, or Guest. Then you could also include "sponsored by" and "guest of" fields, so you see who paid for them if they did not pay themselves.

Are they looking to see who still needs to pay for their tickets? Or are they just interested in seeing the general level of commitment to the event based on who paid for whom?

I think it's more the latter. We have several different membership types, and they allow the member to bring different numbers of guests to events depending on the membership level. I think having this information will give them a better idea of the relationship between membership and event revenue and help us decide if we want to change membership benefits, etc. It may also help determine the number of free-for-members events we hold each year.

Thanks for the suggestion, I will have to see how this pulls for us, but I don't think we even make that distinction when creating Participant records, and just call everyone a "Registrant" by default. We don't do a whole lot "by the book" when it comes to the Events module--of all of the organizations I've worked for, this is the one that seems to care the least what we track there, and since I am cleaning up the rest of our RE: system which is a mess, I am certainly not looking for extra work! If they're happy, I'm happy.

That being said, it's starting to look like changes in procedure may be necessary to get the right info if we're just not tracking the right stuff at present.

THanks again!

Ryan Hyde · June 2016

Yeah, we used to just call everyone a "registrant," but after learning how the different types are intended to work, we switched it up.

Basically:

- Sponsors are organizations or people who buy large groups of tickets. Think table captains, etc.

- Registrants are either people who buy one or more individual tickets OR people who are being sponsored. You can either link them to a sponsor or not

- Guests are guests of registrants. They must be tied to a registrant's record.

It's a little wonky, and I would prefer a system with only two levels (aren't registrants who are sponsored just basically guests of that sponsor anyway?), but if you start setting up future events with that system in mind, getting your folks the info they need should be pretty straight forward. I wouldn't waste time on cleaning up past events though. The events module is so slow and clunky that any retroactive work would be an absolute nightmare.

Daniel Noga 2 · June 2016

Ryan Hyde:

Yeah, we used to just call everyone a "registrant," but after learning how the different types are intended to work, we switched it up.

Basically:

- Sponsors are organizations or people who buy large groups of tickets. Think table captains, etc.

- Registrants are either people who buy one or more individual tickets OR people who are being sponsored. You can either link them to a sponsor or not

- Guests are guests of registrants. They must be tied to a registrant's record.

It's a little wonky, and I would prefer a system with only two levels (aren't registrants who are sponsored just basically guests of that sponsor anyway?), but if you start setting up future events with that system in mind, getting your folks the info they need should be pretty straight forward. I wouldn't waste time on cleaning up past events though. The events module is so slow and clunky that any retroactive work would be an absolute nightmare.

That sounds like how it was done where I worked previously. I'd stick with using Registrants solely for ticket purchases and lump all other "guest"-type people together under Guest.

I am so totally with you when it comes to Events being slow, and I think that's one reason it is not relied upon at this Museum as heavily as it could be. I know, for example, that even with our annual dinner that draws upwards of 2,000 guests, we don't do a single lick of the seating in Events. We abuse the Actions feature to handle seating for sponsorships and such. I was incredibly dubious when I first heard about this upon starting my job here, but when I saw how they handle it, I applauded them for coming up with something so effective that keeps me from staring at screens while RE: thinks!

Ryan Hyde · June 2016

Oh god, I can't imagine using RE Events for 2,000-guest events. I suffer through our annual gala enough, and we top out at 400 guests there.

Daniel Noga 2 · June 2016

Ryan Hyde:

Oh god, I can't imagine using RE Events for 2,000-guest events. I suffer through our annual gala enough, and we top out at 400 guests there.

The luncheon where I worked previously was of similar size. It was agonizing. I'm not kidding when I say it took 5 minutes to load the Seating screen every time we opened it. Needless to say, we kept it open all day if we possibly could.

Ryan Hyde · June 2016

Daniel Noga:

Ryan Hyde:

Oh god, I can't imagine using RE Events for 2,000-guest events. I suffer through our annual gala enough, and we top out at 400 guests there.

The luncheon where I worked previously was of similar size. It was agonizing. I'm not kidding when I say it took 5 minutes to load the Seating screen every time we opened it. Needless to say, we kept it open all day if we possibly could.

Right! Which works right up until anyone else wants to view or edit something. Either you close it to let them in, or they have to wait 20 minutes for it to load while you're in it.

This is certainly not Blackbaud's best module.

Daniel Noga 2 · June 2016

This is certainly not Blackbaud's best module.

I haven't done it all yet, but Events and particularly Seating has my vote as worst neighborhood in RE:.

Jen Claudy · June 2016

Daniel Noga:

This is certainly not Blackbaud's best module.

I haven't done it all yet, but Events and particularly Seating has my vote as worst neighborhood in RE:.

Tried to use Seating once, about 7 years ago. Gave up quickly.

I've always felt that the Events Module was developed separately and then shoe-horned into RE.

shani traum · June 2016

Mainly because our seeting assignments are changing up until what seems like the last minute, we tend to do the chart outside of RE. Once the event has been held (and therefore no more changes can possibly be made!) we enter in the seating chart as a reference for the next time the event occurs, or these same folks get together.

Including Gift info in Participant export

Comments

Categories