I have just had a donor come through via a Blackbaud donation form who was flagged as new in the online data review area. He is on our database as Andy but had put Andrew on the donation form. All other details were identical, address, email address and phone number, but the review tool didn't make a single suggestion about possible matches. When finding and linking him to the existing record, it said the address didn't match even though it was the same, and the phone number didn't match because the donation form brings it through with +44 at the beginning but we record it as 0 at the beginning of a phone number. This also needs to be changed as we don't dial +44 in the same country!
Yes. So much frustration in seeing No Matching Address on Record and it is the same address just with a minor difference for directional or type of street.
And I 100% echo Carlene regarding the autocomplete on Blackbaud forms stripping away apartment or suite numbers.
I agree! Today it was unable to match "10 E Lee St Apt 2606, Baltimore" with "10 East Lee Street, Unit 2606, Baltimore". Maybe some setting like NCOA that allows it to match against postal abbreviations, or some confidence match settings like the Dedupe tool?
I strongly support this idea and want to add some context that makes it even more urgent.
Two recent developments have made the matching issues described here significantly worse: the rollout of Common Record Engine and the introduction of Constituent Forms. Constituent Forms are specifically designed for donors and alumni to update their own information. But if ODR can't correctly match an incoming record to an existing constituent because of a nickname versus a full name, a minor address variation, or a phone format difference, that self-service update either creates a duplicate or lands in a manual review queue. Either way, the whole point of the form is defeated.
The address matching problem gets even messier when you factor in the geolocation autocomplete tool currently used on Blackbaud forms (see related idea: RENXT-I-9269). That tool frequently strips secondary address information like apartment numbers. So a constituent who already has "123 Main St, Apt 4B" on file submits a Constituent Form, the autocomplete drops the apartment number, and ODR flags it as a non-match. The constituent tried to update their record and made things worse instead.
Now layer Common Record Engine on top of that. Data flowing between RE and other Blackbaud products means these matching failures don't stay contained to RE anymore. They ripple out across the ecosystem.
Better constituent matching in ODR isn't optional. Without it, every other data hygiene effort is undermined at the source.
It would also be helpful to have advanced search in the online data review to help narrow down the possible matches. In the US spanish last names are really common. I don't want to have to search through every Rodriguez we have in our system. It would be helpful to also choose to narrow it down by name and state for example, or by last name and phone number.
While reviewing the constituent data for online donations (web view), we have the choice to only "see" the information and either add a new address or mark a phone primary/previous.
I would like to have the option to be able to go into the actual record — as I'm doing the reviewing — and update any necessary information on the donor record. For example, we may have mistakenly marked a phone number as "bad" or "previous" but now the donor is using that exact number. Or, the donor updated their address, maiden name, etc. The constituent ID number isn't shown on the review data either, so it would help to be able to get into the record to verify information before matching.
We need to get into the donor record and do updates as we can in DBV using Online Express. And donor address should be an option to add as a required field on the donation forms as well.
We had a donation come through the online data review. All the data in the donor's form matched a donor's profile except "Road" in the address, was listed as Rd. We process thousands of donations and tons of them will have small discrepancies like this which cause additional work. Is there a way to fix the system so that it doesn't flag "Road" vs. "Rd" or "Avenue" vs. "Ave" on the online review?
I absolutely agree. Constituent matching just doesn't work right. Many people have more than one email address and if they use one that isn't already in their constituent record, NXT does not match it or offer it as a potential match. When several bits of data are identical, as with the original post, NXT should offer it in a list of potential matches. There is also a problem with matching spouses. Constituent Jane Doe bought a ticket for her husband, John Doe (not a constituent, but is included as spouse in Jane's record). NXT did not find John Doe and wanted to create a new constituent record. There are similar problems with folks using company credit cards to purchase tickets or pay for sponsorships which is very common.