Gift Entry: AKA How To Eat An Elephant

Published

In the upcoming weeks, we’ll roll out “Add Gift” capabilities in the web view in waves. While I’m very excited about this, I wanted to preemptively share our strategy and focus for gift management features in the web view.

As I’m sure you’re aware, Raiser’s Edge has deep feature sets that offer a wide variety of optional capabilities. Over the past year, I’ve come to respect that this is especially true with gift entry. So… it’s now time to build gift entry in the web view. All of it. Eventually. How do we eat this elephant? Everyone knows the answer is “one bite at a time”, but how do you figure out the first bite? Many times, that question is much harder to answer.

Strategy for Building Out Gift Management in Web View

Our “first bite” has a very specific purpose – to enable you to completely revamp how you accept payments and enter gifts in a way that is more convenient, streamlined, and “PCI-approved” than what you do today. Our goals with this first bite are perhaps best explained through a use case I’ve seen all too often. Imagine the following scenario:

A donor calls your organization to make a donation. After being transferred, they eventually reach someone who can accept their generous gift. After answering basic questions, the donor is asked to read their credit card number or bank account details over the phone. The payment information is written down (perhaps on something as simple as a Post-it note) and stored (for the most part, securely) for processing later. At the end of the day or week, the hand-written information is entered into a batch in Raiser’s Edge for processing. It’s only then when the gift processor discovers the card or account information is invalid, or that payment is rejected. Fast forward to the awkward phone call where the gift processor has to admit they recorded the information incorrectly (days ago) and asks the donor to retrieve their card or account information and repeat it. (This, of course, assumes the donor’s phone number was even recorded and they answer their phone on the first attempt, which is rarely the case.) Eventually, the payment is processed, and both the donor and gift processor go on about their lives. But at what cost? The gift processor’s workflow has been disrupted significantly (even if this only happened for a single donation), the money took way longer than it should to impact your mission, and the donor walks away with questions and concerns about the organization they chose to support.

This scenario isn’t intended to belittle or shame any process you may have in place today. As your partner, we (Blackbaud) haven’t given you the tools and capabilities to handle this in a more effective, efficient, or secure manner. You’re not doing anything “wrong” by following the script above; it’s just a function of the state of gift processing in Raiser’s Edge. So, if it sounds familiar, do not be ashamed!

Here’s the good news: The first release of “Add gift” in web view aims to change this script. You'll have the power to process credit cards (pre-approved in real-time!) via one-off gift entry forms within Raiser’s Edge NXT — in a super convenient, mobile responsive, and secure way! You will hold (literally, in the palm of your hand) the ability to enter a gift into Raiser’s Edge NXT and simultaneously process a credit card (or direct debit using Blackbaud Merchant Services) payment in a fully secure manner!

ec199f1c65119094a073f7177df021e4-huge-ad

What You Can Expect as We Build Gift Management in Web View
Before I wave my “Mission Accomplished!” banner and drop the mic, I want to be up front. There’s a lot of work to do around gift management in web view. There are a number of things you will still need to do in database view after this release. But don’t worry! We’ll continue to release support for gifts until you can tackle every aspect of gift entry and management in web view — in a way that makes you forget how you ever operated in database view!

I realize that not having certain aspects of gift entry in web view on Day One may mean some of you can’t use it yet (at least not without changes to your policies and procedures, which may not be a realistic option). However, even if you can’t use the capabilities day-to-day, I encourage you to kick the tires and let us know what you think about the feature as it evolves. The entire goal with this initial release is two-fold:

Release a capability that helps some of you operate more effectively and efficiently for certain workflows on a daily basis
Demonstrate progress toward a journey that ends with everyone performing all gift entry and management tasks in web view

For example, even if you decide you can’t use it until tributes are supported, give it a test drive. What do you think of the overall look and feel? Love it? Hate it? Let us hear it! You can reach me through the Community using the link in my name below, or comment on this blog post.

Part of the point here is “showing our work” so we don’t waste time building something fundamentally flawed that we could’ve improved along the way.

I hope that even those who can’t use this capability yet will take this release as a sign we’re moving forward and committed to meeting your needs in coming releases.

Over the coming months and quarters, look for these gift management feature enhancements from my team:

Basic one-off, one-time gift entry forms
Incremental enhancements to the released capabilities based on feedback and needs
Basic batch entry capabilities for one-time gifts, building on the workflows established with one-off forms
Data entry work center and gift batches for incoming gifts
Support for automated (yes... I said automated) recurring gifts entered through the back office
Donation form capabilities that streamline the donor experience and gift entry processes
Enhancements to batch entry that expedite data entry and batch review
Support for pledges and pledge payments
Support for more gift entry needs -- tributes, benefits, and required fields
Enhancements to the online donation form experience -- donor cover, donor portal, and/or pledge support
Support for additional gift types such as Gift-in-kind, Stock/Property, Planned/Legacy, and Other

There will be plenty of enhancements I haven’t specifically called out. Hopefully you’re as excited as I am about this journey, and I look forward to your reaction to the capabilities we have in store!

I welcome constructive conversations and comments in regards to this post, or our approach to gift management in web view in general. Feel free to say hello in the comments below, question me at a user group, or high-five me at BBCON – all are welcome!

For more information about upcoming features and capabilities similar to the ones referenced in your post, please register and join us for upcoming RE NXT roadmap webinars.

Jarod Bonino
Principal Product Manager, Raiser's Edge NXT

News Blackbaud Raiser's Edge NXT® Blog 08/14/2018 12:39am EDT

Added by Jarod Bonino

12 Comments

Heather MacKenzie Oct '18

Hi Jarod, I'm in agreement with others here who have talked about resolving issues that cause problems with data health and integrity prior to building new functionality/replicating functionality. I appreciate very much that you have put this post out there, both for transparency and for those who want to go this for a test run! That is great. We sometimes beat you up with our comments, but know that it's because you are our conduit, and not necessarily that we think you are the sole cause of our frustration(s). So awesome to go to your presentations at BBCon!

Drew Matthews Sep '18

My largest concern about this method of gift entry is PCI related. Allowing development staff to use any web enabled computer that is connected to our network would expose our organization to a new level of PCI reliability/responsibility (as I understand it) and also the resulting costs. We have put a significant amount of resources towards avoiding PCI related exposure on our networks. The whole organization has made significant changes to keep card number data entry off of our networks and the PCI responsibility on the payment processor and their networks. On the Development team, we have a computer that has very limited access to the internet that we use for recurring credit card number data entry using the associated keyboard. This traffic is on our network but is tightly controlled, specifically to avoid PCI related exposure. All other credit card entry that we handle (one time gifts) is done using a card terminal that is on a different network.
I don't think that we would be able to allow this method of gift entry without overcoming some significant internal hurdles related to the additional PCI exposure. We would also have some additional challenges related to gift processing controls/procedures/policies and how we communicate with our Accounting team.

Karen Knisely Sep '18

Dear Jarod – I have two replies to your news. The case scenario that you described above can easily be solved by asking everyone in your organization to enter any gift made over the phone by going to the organization’s Donation website and filling it out for them. This ensures that all staff are familiar with your Donations page, security since the CC # is not written down and it doesn’t hurt to get their personal information just in case it has changed. Just make sure that the website has a Notes section for the staff to make any notes on the donor’s behalf.
Here is where I am imaging the “Add a Gift” to work in NXT. Say you are at an event (where we need easy donations the most) and the person comes up and says they want to make a gift. The staff goes to NXT on their phone or iPad and finds the donor. They click on Add A Gift. They enter an Amount and a Note (to clarify the origins of the gift or donor request) and swipe the card (Success or failure is known right away). The donor is all set!! All the information goes to the same place as the OLX transactions only all the personal information is filled in automatically and the credit card is processed. The notes data can go to the same field as used in OLX. The next day the gifts processor reviews and puts it into a Batch with all the other pertinent donations. So, what I am suggesting is that you already have a way to transfer data from the donations website to OLX – why not use those same “pathways” (APIs?) to enter donations from “Add a Gift” to OLX? Hope that makes sense. I agree with the other commenters – the use of Batches is not going away any time soon since our Finance Dept is requiring it too.

Charles Babian Aug '18

This is very exciting. I think our reason for not being able to adopt right away has to do with our Business Office. One of the reasons we're so tied to the "old way" is their need for documentation of the gift (validations and commitment reports) to trace the gift to the GL. This might be their problem, but I'm left with the task of helping them. Entering a gift on the donor record leaves us without that documentation, so we might need to await the batch function. I want to second the thought about soft credits that Bill Connors brings up. Another big issue for us with ALL gift entry is credit and soft credit. A great deal of our support comes via donor advised funds. Our business office requires us to credit the fund - and soft credit the donor. But reports don't allow for an easy way to see the soft credit donor donor. When asking who gave to the Annual Fund I find that the Communal Fund gave $80K! But that's really 8 donors. And when trying to create lists of donors to ask again for the next appeal -- or for the donor honor roll -- I need those soft credit names. We're really struggling to get the right information sometimes -- are we the only ones? Really looking forward to the roll out of Add Gift (especially what reports I will get!)

Jarod Bonino Aug '18

@Dana - I am still keeping an eye on this post!

The answer to your question is fairly dependent on the currently workflows, policies, and procedures that you have developed with your finance team. I definitely don't want to give you any advice that would make reconciling with finance more difficult.

That said, I have worked with organizations in the past who followed "all gifts must be entered through batch" policies for a few reasons:
1. It was easier to just learn one way to enter gifts
2. If used to be the only way you could process credit cards and direct debits. If you're entering all of those gifts in batch, might as well enter them all there.
3. It's a nice grouping mechanism that makes it easier to report and reconcile

I would argue that 1 and 2 are not relevant here. If you are asking this question, then it sounds like you are willing to learn a new way to enter gifts. :) And I can confirm that "batch" is no longer the only way to process payments. So ultimately what you need to figure out with finance is what other grouping mechanism could be used to post (or report) gifts to finance.

Some organizations enter all their gifts in batch and at the end of the day/week/month run the post process (or print a gift detail/summary report) filtered by batch ID. In most cases I've seen, they could run the same processes/reports according to gift date (or post date) to produce the same list of gifts. In some cases I find it easier to reconcile in this manner, depending on how everything is organized.

The "All gifts entered through batch" policy is GREAT for checks and cash (because you can effectively mimic the deposit that is brought to the bank), but it can get trickier with digital payments. Often times there are multiple batches of gifts whose payments are in a single disbursement. Sometimes there are gifts in a single batch whose payments are split between disbursements.

All this just to say that I do know batch is a helpful grouping mechanism and reconciliation construct, but there are other (in some cases, perhaps better) ways to fulfill the same exercise. The key is to talk to your finance team about the objectives and see what other grouping mechanisms, reports, etc could be used in lieu of a batch control report or post process filtered by batch ID.

Thanks,
Jarod

Jarod Bonino Aug '18

@Donella - The credit card processing aspects mentioned here do work with more than just Blackbaud Merchant Services, however iATS is not one of the supported payment gateways. If you have a "Merchant account" set up in RE under Configuration > Business Rules > Merchant Accounts that uses any one of the following as the "Gateway", you should see the option to enter card details (and subsequently, process the credit card):
-Blackbaud Merchant Services
-Authorize.Net
-Cybersource
-Payflow Pro
-Sage

Thanks,
Jarod

Dana Troy Aug '18

Hi Jarod - good to see progress being made, but do you have any suggestions on how we’d be able to try this out when we need to reconcile with our Finance department (who use Finincial Edge) by batch? If these gifts go into RE individually outside of a batch I don’t know how we would do that. Not sure if anyone is monitoring these posts, but I’d love to get someone’s thoughts!

Kylea Johnson Aug '18

Big thanks to Blackbaud for going through this (probably painful) process in order to let us critique and provide input.

Cathy Spencer Aug '18

Thanks for the info, Jarod.

Bill Connors Aug '18

Thanks for this post, Jarod. I would love to see prioritizing solving soft credit problems with gifts--things that RE 7/the database view can't handle well--over replicating functionality in the web view. Even if gifts have to be entered in the database view and then refined in the web view, I'd rather do that than wait even longer to do things that can't be done at all while you "simply" replicate what can be done in the database view. Thanks.

Donella Robb Aug '18

Hi Jarod,
Is this for organizations using Blackbaud Merchant Services only, or will it work with third-party partners such as iATS?

Mike Adams Aug '18

Very exciting!