Two Google Maps searches can return the same dental practice. Two branches can share a website and phone number. A business can already exist in your CRM under an older name. Importing every row as a new company turns those normal situations into duplicate accounts and conflicting records.
A useful import process answers three questions before any upload: which business location does this row describe, does that location already exist in the CRM, and which fields should the import be allowed to change?
This workflow takes saved G Maps Crawl records through normalization, duplicate review, field mapping, and a small test import. The worked example uses fictional dental practices. It describes a preparation process you control, rather than a native G Maps Crawl CRM integration.
Keep a source copy and an import ledger
Save the original export or structured response before changing column names or merging rows. It gives you a reference when a cleaned value, duplicate decision, or CRM match needs explanation.
The Online scraper supports CSV, Excel, and JSON exports on eligible paid Online plans. Keep business identifiers and source URLs among the exported fields. An all-fields JSON export preserves the complete structured records; a selected-field export contains the chosen columns.
For an API or MCP workflow, save the returned businesses in your application or editor. Search returns up to 20 businesses per page synchronously. MCP does not expose a separate file-export or CRM-import tool, and API access does not unlock Online exports.
Create an import ledger beside the source file. Give each source row a local reference, then record its proposed destination record, action, reason, and review status. Actions might be create, update, hold, or duplicate_of. These are your workflow labels, not fields supplied by the scraper.
The ledger makes cleanup reversible. Removing a duplicate from the import file should not remove the evidence that it was collected.
Decide what one CRM record represents
For a territory-based agency, one record per business location may be the right unit. For an enterprise sales team, several locations may belong under one parent company. Make that decision before deduplicating.
Keep the location identities even when the CRM groups them beneath a parent. Two branches with the same brand, domain, and central phone number can still have different addresses, Maps URLs, and Google Place IDs. Shared contact details are a clue about a relationship, not proof that the locations are duplicates.
Use the returned Place ID as a strong matching key when available, with corroborating location evidence when records conflict. Preserve other source identifiers too. Do not assume an external identifier will never change, or that two different identifiers can never describe the same real business.
When identifiers are missing, normalized name, address, phone, and domain can help build a review queue. They should not silently authorize a merge. A similar name can describe an unrelated practice; a shared phone can belong to a booking service or parent organization.
Normalize values without inventing information
Keep original values alongside normalized comparison fields. Trim surrounding whitespace, standardize empty values, and compare website hostnames consistently. Preserve the complete original URL when you derive a domain for matching.
Store phone numbers and postal codes as text. Preserve a leading plus sign and leading zeroes. Normalize phones only when the country context is known; do not add a country code simply because the search query mentions a city.
Treat an unknown rating as missing, not zero. Treat an empty website as “no website returned,” not a confirmed absence. A source field that is unavailable should not overwrite useful information your team already verified in the CRM.
Preserve observation dates during this step. G Maps Crawl can reuse complete Maps details for up to 730 days, and query responses normally have a 24-hour cache window. Receipt time is not observation time. A newly downloaded file should not automatically win a conflict with a recently verified CRM record.
Work through the duplicate decisions
The rows below are fictional and use illustrative identifier labels. They demonstrate decisions, not actual Google Place IDs or live search results.
| Source rows | Evidence | Import decision |
|---|---|---|
| A1 and A2: Example Dental, North location | Same Place ID label and matching address; returned by two queries. | One location record; retain both source references. |
| B1: Example Dental, South location | Different Place ID label and address; same brand domain. | Keep as a separate location; optionally associate with the same parent. |
| C1: Example Dental Care | No Place ID available; similar name and a shared phone. | Hold for identity review rather than merge by similarity. |
In this example, four source rows produce two location records ready for destination matching and one unresolved record. The held row remains in the ledger. It does not disappear or become a third confirmed practice.
If two copies of the same location disagree, record the conflicting field and the evidence dates. Choose a value under a documented rule or ask for review. Keeping the newest whole row is convenient, but can discard independently verified contacts or a useful value missing from the newer copy.
Map to CRM fields before uploading
Prepare a short mapping document that distinguishes company identity, location data, and contact data. Check the target CRM's actual object model and import controls rather than assuming it uses your spreadsheet headings.
| Prepared field | Purpose | Import rule |
|---|---|---|
| External location identifier | Match later imports to the same source location. | Use a supported destination field or maintain an external mapping. |
| Business name and address | Describe the location. | Review conflicts with existing verified information. |
| Phone and website | Keep available public business contact details. | Do not replace populated fields with missing source values. |
| Maps URL and observation date | Preserve an evidence trail. | Retain alongside the import batch reference. |
| Discovered email | Store a separately reviewed contact channel. | Do not convert a generic business inbox into a named owner contact. |
Match against existing destination records before creating new ones. Where supported, use the CRM's record identifier for updates. If the target cannot store your source key, keep a separate mapping between source location and destination record ID.
Prepare the CSV for its actual destination
Use a CSV library to escape commas, quotes, and embedded line breaks. Then handle spreadsheet interpretation separately. Ordinary CSV quoting does not prevent a spreadsheet from interpreting externally supplied text as a formula.
Use the full structured JSON as the authoritative source for transformations, and prepare separate CSV outputs for spreadsheet viewing and CRM import. G Maps Crawl's CSV export already prefixes some formula-shaped values with a protective apostrophe. Do not remove leading apostrophes indiscriminately: genuine source text can begin with one. Derive CRM values from the structured source instead.
Keep an untouched source copy and apply explicit text handling to untrusted columns in the viewing copy. Check the intended spreadsheet's import behavior, including after saving and reopening. There is no universal escaping strategy for every spreadsheet and downstream consumer; OWASP's CSV injection guidance explains the tradeoffs.
For a CRM upload, map phone numbers, postal codes, identifiers, and source URLs to appropriate text fields. Inspect the preview for truncated identifiers, changed phone formats, shifted columns, and unexpected record counts before accepting the import.
Test a small batch, then reconcile it
Start with a few reviewed rows that cover a new location, a known existing location, and a separate branch. Exclude held records. Review destination automation and assignment behavior before choosing a test environment or a controlled import batch.
After import, compare intended actions with what happened: created, updated, rejected, or unexpectedly duplicated. Record destination IDs and errors in the ledger. Keep the batch small until these outcomes match your expectations.
A complete handoff consists of the source file, normalization rules, duplicate decisions, field mapping, final upload, and reconciliation ledger. That is enough context for another teammate to repeat the import without guessing why two rows were merged or a branch was preserved.
Export your saved results, then prepare the smallest import you can inspect from source row to destination record.
