Cause: Historically, a phone lookup only matched if the number was typed in exactly the same format as what's stored in the CRM — a stored (555) 867-5309 wouldn't match an incoming +15558675309, so Velaro created a second contact instead of finding the first one.

Status: Fixed for HubSpot. The same normalized-match logic (strip formatting, resolve a leading country code before comparing) is being rolled out to NetSuite, Dynamics 365, and Salesforce.

If it's still not matching after the fix ships for your CRM:

1. Confirm the number stored in the CRM is a real, dialable number — not a placeholder or extension-only value.
2. Open Integrations → [your CRM] → Data Mapping and confirm the field mapped to Phone is actually the field the number lives in on your account (see the CRM-specific notes below).

CRM Sync: Duplicate contact created for a number that should have matched

Cause: Usually the same underlying formatting-drift issue, on a record created before the phone-normalization fix shipped. Normalization only changes how new searches match going forward — it does not retroactively merge records that were already created as duplicates.

Fix: Use Contacts → Merge Duplicates to combine the records. Velaro groups likely duplicates by shared email or phone number for you to review and merge in one click — see the CRM Contact Sync Guide for the full walkthrough.

CRM Sync: AI asked to confirm instead of creating a contact automatically

Cause: Not an error — this is intentional. When a phone or name match is close but not certain (a short/partial number, or a near-match name), the AI does not guess. It surfaces the closest existing contact and asks for confirmation instead of silently deciding, so it doesn't either create a needless duplicate or misattribute a conversation to the wrong person.

What to do: confirm whether the visitor is the same person as the suggested match, or continue to create a new contact if they're genuinely different. An exact email or fully-normalized phone match never triggers this — it only appears for genuinely ambiguous cases.

NetSuite — Phone search returns no match even though the customer exists

Cause: The same phone-format mismatch described above. NetSuite phone search is being updated to use the same normalized-match logic already shipped for HubSpot.

Fix: If this still happens on an existing customer record after the update ships, confirm the phone field mapped in Integrations → NetSuite → Data Mapping is the field NetSuite actually stores the number in — some NetSuite accounts use a separate Mobile Phone field instead of the primary Phone field.

Salesforce — Phone search returns no match even though the contact exists

Cause: The same phone-format mismatch described above. Salesforce phone search is being updated to use the same normalized-match logic already shipped for HubSpot.

Fix: Confirm the phone field mapped in Integrations → Salesforce → Data Mapping points at the field the number is actually stored in on your org — Phone, MobilePhone, or a custom field.

HubSpot — Phone search matches the wrong contact for a long international number

Cause: A rare edge case in early versions of the normalization fix — a long international number (11+ digits, e.g. a UK number) could have its last 10 digits misread as a standalone US-format number, matching an unrelated US contact.

Status: Fixed. International numbers with more than 11 digits are no longer reduced to a 10-digit candidate for matching.

Related reading

• Why Do I Keep Getting Duplicate Contacts in My CRM? — plain-language overview of the root cause and the fix.
• CRM Contact Sync Guide — full contact-matching, sync, and merge-duplicates reference.
• Integration Troubleshooting Guide — connection, permission, and other integration errors.