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).?
I set aside 5 minutes per check every Friday to try to make sure everything is correct. That means in addition to the obvious:
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:
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:
I have also been asking what big businesses do outside of nonprofits. They struggle, too, apparently. They do things like:
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:
The user mega-story:
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.
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.?
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.
领英推荐
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:
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 pai
.
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.
?? Salesforce CRM Consultant
4 个月Very interesting piece ! Thank you Terry L Cole