Three John Smiths and the Mailer to a Deceased Donor

The phone call no advancement leader wants

The VP of Advancement is in a meeting when her phone buzzes. It’s a board member.

“I just got a reunion mailer addressed to my late husband. He passed away two years ago. I called you about this last spring.”

Nobody on the team did anything wrong, exactly. Somewhere in the database, there’s a duplicate record. The deceased flag is on one of them. The reunion list pulled from the other. The mailer went out, and an institution that prides itself on relationships just sent a letter to a dead man — for the second time.

Every advancement leader has lived a version of this story. Sometimes it’s a mailer to a deceased donor. Sometimes it’s a “Dear Mr. Smith” letter to someone who’s been Dr. Smith for twenty years. Sometimes it’s a thank-you note sent to an old address while the new one sits in a duplicate record. Sometimes it’s a wealth screening rating attached to the wrong “John Smith” entirely, and a gift officer spends a week chasing capacity that doesn’t exist.

The common thread: duplicate records that everyone knew were there and that nobody had the time, the tools, or the nerve to clean up.

Why duplicates accumulate

Duplicates aren’t a sign of a careless team. They’re a structural inevitability of how data enters the system:

Giving day produces hundreds of new constituents who might already exist. Under deadline, some of them get created fresh rather than matched.
A wealth screening vendor sends a file with their own name conventions. A few records match cleanly; a few create twins.
An alum changes their name after a wedding. The new name comes in through a survey form. The old record stays.
A reunion form captures a constituent under a casual nickname. The formal name lives on the original record.
A parent and a child share the same first and last name. Sometimes a gift gets attached to whichever record came up first in a search.

Every advancement shop has these. Some have hundreds. Some have thousands. The bigger the institution, the bigger the pile.

Why the slow way is genuinely scary

The honest reason most teams don’t aggressively merge duplicates is that the merge itself is risky. Here’s what your data steward is actually worried about:

Picking the wrong survivor. If you keep the wrong record, you lose the better address, the better phone, the more complete biographical data, or the more accurate constituent codes.
Losing gift history. If a merge doesn’t carry gifts forward correctly, the donor’s lifetime giving drops overnight. Finance notices. The donor’s recognition society membership disappears. The donor, eventually, notices too.
Losing contact reports. Years of gift officer notes — visits, calls, briefing prep — live on the loser record. A botched merge silently erases institutional memory.
Breaking related entities. Opportunities, pledges, soft credits, household relationships, recognition entries, marketing list memberships, volunteer assignments. Each is a thread that can be cut by a careless merge.
No undo. Once two records become one, Advance doesn’t have a clean way to put them back.

That risk pyramid is why most institutions have a “merge policy” that’s basically only the DBA can do this, and only one at a time, and only after a careful review. The result is a backlog that grows faster than it gets worked.

What a real merge has to handle

When you actually break the work down, here’s what every duplicate merge requires the person doing it to think about:

Which record is the survivor? Based on which field — most recent activity, most complete data, highest gift total, most contact reports, primary household member?
For every field where the two records disagree, which value wins? And what’s the rule — newest, longest, non-null, specific source?
What happens to related records? Every gift, opportunity, contact report, address, phone, email, relationship, marketing list membership, awards, ratings, affiliations, society memberships — does it move, copy, get re-parented, or get dropped?
What about activities and notes? They almost always need to follow the constituent. But sometimes a note refers to “this duplicate” specifically and shouldn’t.
How do we audit this? Six months from now, when someone asks “did this gift used to be on a different record?”, the answer should be in the system, not in someone’s memory.

That’s a lot for a human to track per merge. Multiply by a backlog of several hundred, and you get a process that nobody actually does at scale.

How one institution finally cleaned house

We worked with an institution whose advancement services lead had a spreadsheet of about 600 likely duplicate pairs. It had been growing for years. Every now and then she’d work through ten or twenty. Most of the time, more important fires pulled her away. The list never got shorter.

Then she started running them through Corral Works.

The merge workflow, end to end

Corral’s merge isn’t a “click merge and pray” button. It’s a guided wizard that walks the operator through each decision the work actually requires:

Confirm the records. Side-by-side view of both candidates. Full biographical data, full gift summary, full contact report count, full related-entity counts. Sometimes the operator looks at the two records and realizes they aren’t duplicates after all. That’s a successful step, not a failed one.
Survivor scoring. Corral scores both records on data completeness, recency, gift history depth, contact activity, and entity-specific factors. It recommends a survivor with the reasoning shown. The operator can override — the recommendation isn’t a decision, it’s a starting point.
Field-level conflict resolution. For every field where the two records disagree, Corral shows both values, flags the severity of the conflict, and lets the operator pick which value the survivor will carry. Required fields are checked. Type rules are enforced. Nothing commits without the operator’s review.
Related entity analysis. Every gift, opportunity, contact report, address, phone, email, relationship, marketing list, award, rating, affiliation, and society membership is enumerated. Corral shows what will happen to each — moved, copied, re-parented, retained. The operator reviews the cascade before anything writes.
Entity transfer decisions. For ambiguous cases — a household role, a recognition entry that exists on both records, a marketing list one is on and the other isn’t — the operator decides explicitly. No silent merges.
Final preview. The full proposed end state of the survivor record, in one screen. If anything looks wrong, the operator goes back. If it looks right, they commit.
Audit trail. Every merge produces a complete record of which loser was merged into which survivor, which fields were chosen, which related entities moved, when, and by whom. Reversible at the batch level.

What changed for that institution

Metric	Before Corral	With Corral
Time per merge	30–45 minutes (when it happened)	3–5 minutes
Merges completed per week	5–10, when time allowed	50–100
Backlog of known duplicates	600+, growing	Cleared in a quarter
Confidence to delegate merges beyond DBA	None — too risky	Trained services staff handle routine merges
Audit trail	Manual notes, sometimes	Complete, automatic, exportable

Six hundred duplicates cleared in a quarter. Without losing a single contact report, gift, or piece of institutional memory. With every step reviewed and attributed.

The downstream effects nobody budgeted for

Cleaning up a duplicate backlog isn’t just about hygiene. The institution started noticing things they hadn’t budgeted for:

Lifetime giving totals went up for several major donors — not because anyone gave more, but because gifts that had been scattered across duplicate records finally consolidated. A few of those donors crossed recognition society thresholds they should have crossed years earlier.
Wealth screening data got more accurate. Ratings that had been split across two records consolidated onto the real person. Capacity assessments started reflecting reality.
Reunion lists got cleaner. No more “send this person two of everything.” No more letters to deceased donors slipping through because the deceased flag was on the wrong record.
Contact history got richer. Years of gift officer notes that had been scattered across duplicate records ended up on the surviving record, where the next officer to call could actually read them.
The phone calls stopped. The board member who’d called about the reunion mailer didn’t have to call again.

What this means for leadership

For the CFO: lifetime giving totals you can trust, recognition society reporting that holds up, finance reconciliation that doesn’t surface mysterious gift-routing issues. Audit trails that satisfy compliance without a scramble.

For the VP of Advancement: gift officers walking into visits with the complete picture instead of a fragmented one. Stewardship lists that don’t embarrass the institution. A data steward who isn’t spending half her year on a backlog that never shrinks.

For the CEO: an institution that looks coherent to its donors — because internally, it finally is.

Small teams especially

If your shop has three data stewards and a dedicated DBA, you can throw bodies at duplicate cleanup. It’ll be slow, but possible.

If your shop has one advancement services lead supporting a handful of gift officers, the duplicate backlog is the bottleneck you’ve been quietly working around for years. Every report you pull has caveats. Every list you hand to marketing has known issues. Every wealth screening produces a few “wait, this is the same person” notes that never get resolved.

Corral Works is built so a one-person services team can keep the backlog at zero, not grow it. That’s the bar.

Ready to stop sending letters to the wrong people?

If your team has a duplicate backlog you’ve been avoiding, or if “we have a list somewhere of possible matches” sounds familiar, you’re not alone — and you’re not behind. The tools weren’t built for this work.

Join the waitlist and let’s talk about what a clean database could look like for your team.