The scenario below is a composite, built from patterns we've seen repeated across healthcare sales and marketing operations teams — not a specific client engagement. Any resemblance to a particular company is coincidental; the underlying mechanics, however, are real and worth understanding if your team has ever imported a provider list and had the numbers not add up on the other end.
The situation
A mid-size medical device manufacturer was expanding into a new specialty line and needed to load a refreshed list of several thousand specialist contacts — cardiologists, interventional radiologists, and their affiliated practice staff — into their CRM ahead of a regional sales push. The list came from a reputable data source, was reasonably current, and matched the target specialties the sales team had been asking for.
The import ran. The CRM reported a completed batch. Everyone moved on.
Weeks later, reps in two territories started flagging the same complaint: accounts they knew existed — practices they'd worked before, physicians they'd met at conferences — weren't showing up when they searched the CRM. Sales ops pulled record counts and found the CRM held noticeably fewer contacts than the file that had gone in. Not a rounding error. A gap large enough that entire practice groups were missing.
What didn't work
The first instinct was to blame the source list. That's almost always the first instinct, and it's usually wrong, or at least incomplete. The team re-requested a sample from their data provider, spot-checked twenty records by hand, and found nothing wrong — valid NPIs, correct specialties, current addresses. So they re-ran the import, assuming it had been a one-time glitch. Same result: a "successful" batch, and a CRM contact count that still didn't match the file.
Next, they checked for obvious duplicate suppression — the usual suspect — but the CRM's own duplicate report only flagged a small number of matches, nowhere near enough to account for the shortfall. That report became the thing everyone trusted, which turned out to be part of the problem: it only showed duplicates the CRM's default rules were configured to catch, not everything the import process had actually merged, rejected, or silently altered upstream of that report.
Two weeks were spent this way — checking the list, checking the obvious dedupe logic, finding nothing conclusive, and quietly assuming user error on someone's part.
What changed
The turning point was pulling the full import log rather than the summary. Most CRMs generate a job-level success/failure count by default, but underneath that sits a record-level log most teams never open unless something visibly errors out. That log told a different story than the summary screen had.
Three separate mechanisms were each eating a slice of the file:
Overly aggressive matching on name plus practice address. The CRM's duplicate rule wasn't matching on NPI — the one genuinely unique identifier in the file — it was matching on last name and mailing address. Group practices with several physicians sharing a suite number were getting collapsed into a single contact record, with only the first-imported physician surviving. In a specialty like cardiology, where multi-physician group practices are the norm rather than the exception, this quietly erased a meaningful share of individual providers.
Field-level validation failing without stopping the batch. A subset of records had specialty taxonomy values or credential suffixes (MD, DO, NP, PA) formatted slightly differently than the CRM's picklist expected. Rather than halting the import or flagging an error, the CRM's configuration simply dropped the offending field, and in some cases dropped the whole record, while still reporting the batch as complete. Nothing in the standard summary view distinguished a full success from a partial one.
NPI formatting mismatches breaking the intended unique key. Some records carried NPIs with leading zeros or were stored as a number field elsewhere in the CRM's schema, which silently truncated or reformatted them on entry. Once that happened, the field the team assumed was enforcing uniqueness wasn't functioning as one at all — which fed directly back into problem one.
None of these were dramatic failures. Each one, individually, looked like an edge case. Together, applied across a few thousand records, they explained the gap almost exactly.
The fix wasn't exotic — it was configuration discipline. The team rebuilt the duplicate rule to key strictly on NPI rather than name-and-address, converted the NPI field to a strictly formatted text field to prevent silent reformatting, and added a pre-import normalization step that mapped specialty and credential values to the CRM's exact picklist entries before anything touched the production instance. They also started reviewing the record-level import log as a standing step, not an exception-handling one, and asked their data provider — in this case NPLUS Global — for a delivered-record count they could reconcile against post-import totals every time, rather than relying on the CRM's own success message as the final word.
The outcome
The next import of a comparably sized file landed with a contact count that reconciled against the source file within a normal, explainable margin — not a discrepancy the team had to chase down for two weeks. Territory coverage complaints from the field dropped off, not because the underlying data had changed, but because the contacts that had always existed in the source file were actually reaching the reps who needed them.
Nothing about this scenario required a better list. It required treating "import successful" as a claim to verify, not a status to trust — and understanding that the CRM's own duplicate and validation logic is often the least visible variable in the entire pipeline. For teams handling healthcare-specific data, where multi-location practices, credential suffixes, and taxonomy codes are the norm rather than the exception, that logic deserves the same scrutiny as the data itself.
Ready to see what we can build for your ICP?
Send us your ICP — sample in 2–3 hours, full delivery in 48–72 hours.
Request a free sample →