Subscribe
Share
Share
Embed
Welcome to the Click & Pledge Fundraising Command Center Podcast!
Welcome to the Click & Pledge Fundraising Command Center Podcast – your mission control for mastering modern philanthropy. Every month, we equip you with the insights, tools, and strategies you need to elevate your impact. We believe in understanding the why, mastering the what, and showcasing the how of successful fundraising. Tune in every Monday for a new perspective:
The Why
Start your month with the big picture. "The Why" is our thought-leadership series that dives into the deep, foundational concepts behind our work. Every first Monday, we explore the science, philosophy, and psychology of fundraising, technology, and giving. This show isn't just about what you do; it's about providing a framework for why you do it. Join us as we connect big ideas from neuroscience, behavioral economics, and cognitive science to the future of philanthropy.
The What
Get to know your toolkit. "The What" is our product-focused series where we go "under the hood" of the Click & Pledge platform. Every second Monday, we deconstruct our features, reveal the "story behind the product," and explain what our technology is designed to do. If you want to understand the architecture, the design, and the specific problems our tools solve, this is your guide to the blueprint.
The How
Learn from the leaders. "The How" is our community showcase, where we pass the microphone to the experts: your peers. Every third Monday, we invite nonprofit leaders, fundraisers, and innovators to share how they are using our platform to run successful campaigns, engage donors, and grow their impact. These are their stories, their strategies, and your real-world templates for success.
Welcome to this edition of the Click and Pledge's Fundraising Command Center Podcast, where we taught the why, the what, and the how in the Click and Pledge's ecosystem. Today, we are doing a really critical deep dive. We're focusing on the what and specifically we're tackling one of the most persistent, headache inducing challenges for pretty much every nonprofit administrator out there.
Speaker 2:Oh, absolutely. Data corruption.
Speaker 1:Data corruption caused by duplicate contacts. And you might think, you know, data cleanup is just tedious work, but it really impacts everything, does it?
Speaker 2:It does. It hits donor trust, your ability to personalize communication, and, you know, ultimately how well you can even fundraise.
Speaker 1:So that's what we're digging into.
Speaker 2:And what's fascinating here I think is getting to the root cause, which is just the almost unlimited number of variations in human data entry. Every single time a donor gives online or calls in or fills out a form, there's a chance for a new little twist on their identity.
Speaker 1:A new typo, a new nickname.
Speaker 2:Exactly. So we're going to show you how our system, which we've developed over what, fifteen years now, manages that chaos. We use a feature called temporary contacts and, the power of progressive learning to make sure you maintain truly clean data.
Speaker 1:Okay. So let's start at the beginning. We always understanding why the problem even exists. Why is nonprofit data so, so uniquely susceptible to this duplicate dilemma? I mean, if I buy something online, the data seems clean.
Speaker 2:Ray, it's a great question. It really boils down to what we call the name game and what your system relies on for unique identifiers.
Speaker 1:The name game.
Speaker 2:Yeah. A retail database, you know, uses barcodes, specific account numbers, things that are static, they match easily. Donor data relies on things that are, well, they're fluid. Names, emails, addresses.
Speaker 1:Things that change.
Speaker 2:Exactly. Take for instance the Elizabeth paradox.
Speaker 1:Okay.
Speaker 2:So to a human, to you or me, it's completely obvious. Elizabeth, Beth, Liz, Lizzie, that's the same person to a computer algorithm. A simple one anyway. Those look like four totally distinct separate entities and if the system tries to be too aggressive and just guess, it creates false positives, you end up merging two completely separate donors who just happen to have a similar name. It's a disaster.
Speaker 1:And that's messy enough with just nicknames, but then you add in just the sheer volume of common names. That must break simple matching rules completely.
Speaker 2:It shatters them. We call this the Brown problem. Let's say your database has, I don't know, 3,600 people with the last name Brown. How does the system reliably tell John Brown from Jimmy Brown or James Brown, especially if one of them has a typo in their email that day? Simple last name matching is just it's doomed to fail in a big dataset, and that's before you even get to
Speaker 1:life
Speaker 2:events.
Speaker 1:Like a name change?
Speaker 2:Right. Jonathan Doe donates for years. Then he starts donating as Jonathan Doe Smith. A naive system just sees two completely unrelated people.
Speaker 1:And this isn't just, you know, an administrative annoyance. This is where real data corruption happens. I want to look at a scenario we see all the time. What we call chaotic husband's email error. The Susan Smith scenario.
Speaker 2:Ah, yes. The classic.
Speaker 1:So a lot of basic systems will match just by email address, But if that email address changes, isn't that just treated as a new person? Why is this specific scenario so dangerous that it causes corruption instead of just a duplicate?
Speaker 2:That is the core distinction there. It causes corruption because the identity, Susan Smith, is tied to all the fundraising history, but the communication channel, the email, gets hijacked.
Speaker 1:Okay. Walk us through it.
Speaker 2:Let's picture it. Susan Smith is your long time committed donor. She's rushing to complete an urgent appeal online. She asks her husband John to just handle the payment part.
Speaker 1:Happens all the time.
Speaker 2:All the time. So John correctly enters Susan Smith as the donor name but he types in his personal email because you know he wants the receipt sent right to his phone.
Speaker 1:So the record is still Susan, but the system now thinks John's email is her primary contact.
Speaker 2:Exactly. And if your system just blindly accepts that raw input, Susan's profile is now corrupted with John's email, and the consequence for donor relations is it's just devastating.
Speaker 1:Because the next appeal
Speaker 2:The next personalized appeal address, dear Susan, goes straight to John's inbox. It creates confusion. It damages your professionalism, and it totally undermines the trust you've worked so hard to build. That single scenario shows why relying on raw input is, for us, fundamentally flawed.
Speaker 1:Okay, so let's unpack the solution. If we can't trust the incoming data, and clearly we shouldn't, what is the click and pledge system doing differently? What's that barrier? This is where temporary contacts come in.
Speaker 2:Right. Temporary contacts are that foundational layer of integrity. The best way to think of it is as a crucial limbo or a smart holding tank for any data that's even a little questionable.
Speaker 1:A holding tank, I like that.
Speaker 2:Our whole philosophy here is rooted in what we call progressive learning. And the number one rule is, we do not guess. Ever. We let the human administrator make the call when data integrity is in doubt.
Speaker 1:So walk us through that decision gate, a donation comes in, does the system decide, okay, this is clean versus nope, this goes to the holding tank?
Speaker 2:It's a very precise logic flow. An inbound donation arrives. The system first tries to find an exact match. And we recommend using the most reliable unique triplet you can, which is first name, plus last name, plus email.
Speaker 1:All three have to match perfectly.
Speaker 2:Perfectly. If that perfect triplet is found, great. The system is confident, the transaction is processed, it's assigned to existing contact. But, if no exact match is found, if even one of those elements is off
Speaker 1:Screwed to the holding thing.
Speaker 2:Immediately diverted. It is explicitly not forced into the database.
Speaker 1:I see. Okay. So it sits in that temporary contact queue. That stops the immediate corruption. But how does that help the administrator make the right decision?
Speaker 1:I mean, staring at a list of a thousand names is still a ton of work.
Speaker 2:And that's where the system starts being smart, even while the data is in limbo. For every single one of those temporary contact records, let's say it's a donation from Elizabeth Brown with a typo, the system proactively goes and pulls suggested matches.
Speaker 1:So it's helping you out?
Speaker 2:It's guiding you. It'll show you existing contacts who share a similar last name, or maybe the exact same mailing address, or the same phone number. It guides the human eye directly to the most likely existing record so the admin can make a fast, informed and most importantly correct decision.
Speaker 1:That makes reviewing the queue so much more efficient. But for me, this next part is the key differentiator. The thing that really saves time. The administrator shouldn't have to fix the same mistake like a common nickname every single time, right?
Speaker 2:Absolutely not.
Speaker 1:So how does the software learn from that one human correction to make itself permanently smarter?
Speaker 2:That is the whole beauty of the progressive learning engine. We call the tool that does it the alias mechanism and this is what transforms that simple holding tank into a self improving automated defense system.
Speaker 1:Okay. So let's use that name variation example. An admin is looking at the queue. They see Jay Smith sitting there. They know Jay is just a nickname for your donor, Jonathan Smith.
Speaker 1:What happens when they link those two?
Speaker 2:The second the administrator manually links that J Smith record to the existing Jonathan Smith record, the system sees that relationship. Instantly, it creates a permanent alias record. Think of it as a little historical flag stored in the background. Perfectly put, and this is so crucial for future prevention. The next time Jay Smith donates, it could be tomorrow, it could be three years from now, the system doesn't even have to bother with the temporary contact logic.
Speaker 2:It checks the alias list first.
Speaker 1:And it sees the note.
Speaker 2:It sees the note. It recognizes Jay Smith is a known alias for Jonathan Smith, bypasses Limbo entirely and automatically assigns that donation right to Jonathan. The human never has to touch that specific variation ever again. That's where you start to see massive time saving.
Speaker 1:That is truly powerful. But let's be real. Administrators are busy. Sometimes that temporary contact list gets ignored for a week, maybe even a month. What happens if a recurring donor, say Jimmy, who always types his name instead of James, has five transactions just sitting in that queue?
Speaker 1:Does the admin have to fix all five manually?
Speaker 2:No, and that would defeat the whole purpose of the automation. We know that workflow reality. This is where we introduce the concept of the self monitoring maintenance mode and batch processing.
Speaker 1:The ripple effect.
Speaker 2:The ripple effect, exactly. It ensures the system cleans its own backlog based on your one single action.
Speaker 1:So how does that work?
Speaker 2:So, you have those five transactions from Jimmy sitting there. The administrator only needs to resolve the first one. That's it. Once that first record is matched, linking Jimmy to James, the system understands that relationship forever.
Speaker 1:And then it goes to work.
Speaker 2:Then it starts its maintenance cycle. It actively scans the rest of the temporary contacts in the background. It sees the other four pending transactions are also from Jimmy and says, hey, I know how to solve this now. Within minutes, it automatically processes and assigns the other four transactions to James. The batch gets cleared based on one human decision.
Speaker 1:That saves exponentially more time. Okay, let's talk about the bigger picture of data hygiene. We suggest this philosophy of never deleting data without explicit instruction. Why is retaining that history so critical for a nonprofit?
Speaker 2:It really comes down to auditability and good governance. For things like grant reporting or just compliance, you need a full unchangeable audit trail of a donor's history. If a donor moves and you just delete their old address, you've lost part of the story of their relationship. With you.
Speaker 1:So how do you handle updates? A donor moves, you need their new address to be primary.
Speaker 2:Right. And the system handles that through really granular control over what we call overwrite rules. You can set a rule that says, yes, allow this new mailing address to become the primary contact info. But, and this is the key, instead of deleting the old address, the system automatically moves it to an alias record. It archives it.
Speaker 1:So the current accurate data is what you see day to day, but the full history is still there if an auditor needs to see where that donor lived back in 2018.
Speaker 2:Exactly. You get both. You maintain absolute current data integrity and a full auditable history of that donor's entire life cycle all under one clean contact record.
Speaker 1:We've talked about creating a lot of aliases through this process. What about an admin who's worried about the system getting bloated with, you know, common misspellings or old emails from a decade ago? Can you clean up that alias history?
Speaker 2:Absolutely. You have to. While we believe in retaining history, we also know that managing clutter is important. So administrators have tools to set maintenance rules to automatically purge obsolete aliases.
Speaker 1:Like what?
Speaker 2:For example, old, unused emails, outdated addresses. If they haven't been used in, say, a hundred and eighty days, you can set a rule to just purge them.
Speaker 1:So you get to decide the balance.
Speaker 2:You're in complete control. You preserve the critical donor journey data, but you stop the system from being overwhelmed by useless old data variations. It's a balanced approach to long term data health.
Speaker 1:The whole system then, from that initial gatekeeper to the batch processing and the alias archive, it just gives administrators confidence that every single transaction is well, it's treated with suspicion first, resolved with human intelligence, and then automated forever. So what does this all really mean for you, the listener? By combining this smart holding tank idea with that self learning alias system, the temporary contact feature just eliminates the chaos. It removes the manual work of fixing duplicates and gives you confidence that your donor records are accurate.
Speaker 2:And I'd say consider the power of the Alias system beyond just matching names. It really is a historical archive. It documents the full life journey of a donor, from their first misspelled nickname to every updated address. And that whole history is preserved without ever messing with the accuracy of their current information. It gives you a depth of donor insight that simple database matching, well, it could never achieve.
Speaker 1:For more information about this and all Click and Pledge products, make sure to visit clickandpledge.com and request for one on one training or demo. Whether you are a client or curious about our platform, just ask us and we will gladly get together with you to chat. And don't forget to subscribe to this podcast to stay up to date with all the latest and greatest features of the Click and Pledge Fundraising Command Center.