Gift Entry on the Go

I frequently tell people they probably can’t beat the efficiency of the Gift Entry tool (in NPSP or NPC) in terms of cost. It’s a desktop only tool that is keyboard focused. I use it weekly to enter in our batch of checks. Our batch is typically about 8 checks per week (but that varies wildly from 1 to 20). 

• On average, 5 are directly from donors; 
• 2 are from individual donors but through designated third parties like DAF or retirement accounts; and 
• 1 is a third party gift from a company that bulks multiple donors into a single payment like Network for Good or United Way that send checks still. 

I set aside 5 minutes per check every Friday to try to make sure everything is correct. That means in addition to the obvious:

• new donors and the address data captured, possibly from the envelope, check, or insert,
• bank account partners (usually spouses) captured if a personal check
• offer codes or campaigns captured,
• memo lines and in-honor mentions captured and soft credit assigned,
• any additional notes or emails captured that might have come in with the check,
• check date honored unless something is terribly amiss (and then I go with the postmark),
• the primary donor is the signer.

I honestly feel like I’m sitting for a college entrance exam every time I do a large batch. It requires focused concentration to avoid forgetting something or making an error. How can it be so hard?

As a result, I’ve begun to wonder if we’re doing it wrong??? These thoughts have been reinforced by my exploration lately of:

• better ways to do payment integrations, 
• exploration of the differences between NPSP and NPC fund-raising support models, 
• the new model for dealing with first party data reconciliation offered by data cloud, 
• the discussion of introducing artificial intelligence into the big data landscape, and more. 

But this article is written just about physical donation processing, so I’ll stick to that for now. More is coming on all these topics, however.

I also have been mulling over a question that I get asked all the time: what people do at bigger scale for check processing (and integrations in general). I have talked with quite a few people. Here are my non-scientific conclusions:

• Most hire more super-human clerks, it seems, who master that above. 
• Most nonprofits don’t actually use Gift Entry or batches and just do the tasks at the App at the basic UI level.
• The question of governance and how fundraising CRM and accounting package interact varies widely within nonprofits and have a lot of impact on procedures.
• The issues of better governance and processes is “bothering” lots of nonprofits including physical payment management.

I have also been asking what big businesses do outside of nonprofits. They struggle, too, apparently. They do things like:

• create loyalty programs so they know your check (or cash or gift card) belongs to you. 
• encourage credit card use because it’s more easily tracked (and for other reasons, of course). I don’t believe that most cash registers know you are you! 
• encourage and provide uniquely identified vouchers or stubs to go with your mailed in payment. This shows the difficulty of the problem. 
• employ mailroom software to log incoming mails and packages and notify recipients. I see no obvious solutions inside the Salesforce ecosystem, however. 
• Use computer vision and “AI” to read the amount and account holder address blocks. But such tools are not readily available and integrated with your keyboard and devices (Einstein promised such a solution long ago but didn’t deliver.

With all this on my mind, I went in search of an implementation solution NOW that is a better process and no slower than my current one for processing checks regularly. Several things about what I’m reporting:

• I built a flow TOY that I will use for a month or so to do mail receipt. I’ll train my team to do it as it proves useful.
• I built the toy without making changes to the data model we currently use so that the impact of the learning would be minimal on existing systems and procedures. This isn’t ideal but didn’t seem to get in the way much given our small size.
• I needed the tool to work on my mobile phone and be REALLY fast and allow start/stop type of work in stages.
• I already make heavy use of images in our Salesforce (I call that “visual Salesforce” and believe it, along with AI, will change the idea of what it means to add records in just a few years.) I used SharinPix for this quick pilot.

Procedure Step	Receive	Open	Deposit	Attribute / “Post”
Images	Outside of Envelope	Payment, Back of Envelope,other contents,Witness photo if needed
Data Entry	Auto: date of receipt Optional: Name	Type of Payment or notation of non-payment Optional: Amount	Amount	Account NameContact NameThird PartyMemoDesignationIn-honor/memoryReceipt squelch

The user mega-story:

1. When we receive business mail that is likely to be a donation, we want to record this and create a record that it exists. And we want to do the same for each additional arrival. It should be super quick, easy, and fast and with very minimal, if any, data entry. This is likely at a mailbox, PO Box, or on the go.

• Open our app and click receive. This creates an unnamed donation with a date of today and no further info. 
• Click add photo and snap a photo of the outer envelope with our phone. No need to store locally on the device.
• Optionally add a quick name from the envelop (or create a human friendly handle as part of the temporary donation name

The loop takes about 20 seconds per piece. We currently do something else to document mail received and I think this will actually be faster! The person doing this can be whoever picked up the mail and can also include GPS and timestamp. We now have three mailboxes because we moved, so this is pretty helpful! Over time, perhaps SharinPix or others will show me how computer vision can read the text from the envelope after the save.

2. When it’s time to open the mail in a calm and secure setting where nothing will get mislaid, we now want to add to the existing record. Sometimes it’s not a donation and other action needs to be taken. But other times it’s a donation and ends up in a stack for batch deposits soon. 

• Open our app again and click “open.” This presents you with an image of an unopened mail item.
• Find the right items, open, and snap photos of any payment and click the type of payment or none (check, cash, gift card. Optionally you can enter the approximate amount of the donation to flag specific donations for communication to others. The payment type and amount go in appropriate fields.
• Snap images of the rest of the contents.  And if the back of the envelope has anything on it, snap that, too. 
• Loop through additional envelope images until you’re done. You can stop anytime or skip any that seem inappropriate to open now or that you don’t have.

The important part of this step is to add to the record the actual payment and type as well as all the parts that came with it. You won’t later have to retrieve anything from the trash bin. If you have accountability procedures, you could also include a photo of the witness holding the parts or similar. This is very good for cash, gift cards or cashier’s checks to protect everyone. The flow assigns tags like envelope, payment, and contents at each stage of the flow. The user can delete, retake, and so on as they need. There’s no required data entry at this point or paper forms!  One day (soon perhaps), computer vision and AI can go to work on all the attachments and convert them to free text. Generative AI could then answer questions like donor name, amount, checking account address, return address, check date, check number, etc. 

3. At our org, it’s now time to deposit things. It’s good practice to get things in the bank quickly. 

• We stamp the checks with an endorsement.
• Open our app again, and this time click “Deposit”. You are again presented with an image of an opened payment to find. This time you simply enter the amount of the deposit from the check and click done. Or you can skip.
• Make the deposit of a single item through a mobile deposit tool or put it in the banking pouch for a teller deposit or night drop. Some might use a check scanner for deposits with higher volume. We ask for individual deposits from tellers and night drop rather than bulk deposits so we have one one correspondence on the statement, accounting deposit and Salesforce.
• Loop through this for all the opened payments. The flow skips gift cards and non-payment items at this stage.

I elected to only do the minimum work–recording the amount–so that it remains a very mobile friendly process. Some might prefer to optionally enter the check amount, payer name as text (not necessarily the donor) and check date. This is somewhat logical as it completes the accounting basic data block, I wanted speed and to allow the person to focus mostly on the deposit process. We don’t need it but you could also include an item count and accumulation total to assist with filling in bank deposit slips. 

Do note that now we have collected together a whole donation in Salesforce, but without fully accurate information about everything captured fully in the images, not yet dated per whatever our rules are (deposit date, postmark date, check date, accrual date of notification, etc) and not not yet attributed to anyone specific. We also already have logs of received mail date, opened mail date, and deposit date and amount. And images of everything and records updated or created at each step by the person who performed the step. Pretty slick, really.

4. Now it’s time for the accounting and development team to go to work on the important details that donors and compliance expect. The jobs can be split between departments and even the tasks can be split into jr. and sr. experience levels, and potentially with AI help to make text readily available for cut/paste or extraction. This is how you scale for sure! Here is my procedure intended to be done by two people: a jr. admin to do the first pass and me to do the second pass.

• Open the app on a desktop and click “Attribute”. I recommend the desktop for larger screen and keyboard work although I did this on my mobile, too, successfully. You’ll see a deposited item along with the payment image. 
• Check the amount is right and enter the check date.
• Capture the memo line or any other information that belongs in the description.
• Use the payment and images to select account, primary contact, and any third party. These are all account lookups and you can create new ones if needed.
• Use the envelope or inserts to try to assign a campaign. This is a lookup to existing campaigns.
• You can uncheck the send receipt if you have reason to so that the receipt goes out when you click post. Or you can click update to update information but not finalize the item. Or you can skip.
• Loop through the remaining deposited items.

This process seems to be as efficient as Gift Entry with the added benefits. Admittedly, some records may require more work… new donors set up, in honor and in memory roles added, discussions held about how to attribute or designate the funds, decisions about what proper date is to be used, etc. Sometimes we go update contacts to include spouses or add additional contact information that is in the contents that came with the payment. These can be addressed off-line or assigned as a task and followed-up in Salesforce right on the opportunity record itself. Items not yet posted, remain in the system as opportunities, but they don’t hold up the rest. We also aren’t forced by the process to make a guess that turns out wrong and later has to be untangled.

Is this faster than Gift Entry?… probably not on a good day. But on a bad day–and I admit that’s about half the time, the batch takes two hours because it has too many special payments or because I get distracted and make a mistake or omission. But it is close to the same speed, I think offers some advantages:

• This stepwise method allows us to divide the job up between different functions and locations: mail room, receiving/opening, deposit, bookkeeper and dev team attribution. 
• We can include more team members working at the jr. level, allowing for greater scale, efficiency and bandwidth, for time sharing, and or breaking the task down. 
• We can involve members at the sr. level and from other departments when their experience is needed with a focused task on a single record with all the images to view. 
• With field tracking turned on, we have a change log all along the way in Salesforce. You can see how each pass of the flow made changes and by whom as each item goes from receiving, opening, depositing, and attribution. 
• We have all the images attached. Do note that images must be stored securely. I use SharinPix and permissions. The actual payment image is tagged specifically by the flow and could potentially be protected more in future. Banks block account numbers and signatures of such images, for example. Generative AI could do this pretty soon for us inside Salesforce perhaps.

Note also that the donation record in the user meta-story above can be whatever you want it to be in Salesforce: an Opportunity (NPSP) with or without Payment, a Gift Transaction (NPC), a batch data entry record (NPSP or NPC flavors), or some other custom mail object in Data Cloud. I actually used Opportunities with Payments for my functional toy. You could also create batch entry records and treat all this as a sort of mobile Gift Entry extension. The last step could potentially be performed by “opening” the batch and then opening each record in the batch already.

We’ll test this for a while since the activity occurs once a week normally. I don’t know if this pilot will be a keeper or not. The old Gift Entry process relies on extremely good hygiene and doesn’t create any tracks along the way like this solution does. The old process tends to be a complex one-person task and data entry  MUST be right and complete before batches can proceed. The new system is more compartmentalized by job function and location. The new process generates more documentation along the way with date stamps, employee names, and images. Finally, I found that the data needed to attribute most physical checks is simple. In those more complex cases, I probably am better off receiving a task from my jr dev clerk asking me to complete a task from the general UI rather on a record than maintaining a complex template to try to capture all the challenges of those bespoke situations.

Love to hear from you!

The flow itself for those who like such things:

Flow button bar for vertical presentation with four options as decision branches:

The Receive Loop and Screen:

Note that to attach items to a record you first must have one so it makes a blank donation first. If the user selects no more, it deletes it. The single image is tagged envelope.

The open loop and screen.

It only offers donations that match the conditions known to be how received leaves donations. A payment is created and amount set on both payment and donation to match input. The single image is tagged payment.

.

The deposit loop and screen.

The related payment is marked paid.

The attribute or post loop and screen.

This is the busiest. A button bar is used to allow skipping, updating (without finalizing) or posting (finalizing). I used multicolumn input and form fields to make use of the latest search with filtering by keystrokes for all the lookup fields. This also allows creating new items if needed. The skip decision “exits” without saving. The decision to update or post just impacts the value of the stage of the opportunity. Both payment and donation are updated with values on the screen.

This is implemented with almost all standard features. I think the only thing not out of the box is the flow button bar from unofficialSF.com. It’s really great for making better experiences than just the next buttons. And they can be at the top, middle, or bottom of the page! This took 15 versions to implement each stage and test. I cleaned up the old versions. We’ll see how rapidly we update this to tweak it during our pilot.