Imagine an agency connecting Google Local Services Ads to a client's customer relationship management system. A lead appears, the integration looks successful, and everyone moves on. Then a second notification creates another opportunity. A client changes an outcome that never reaches the report. An old imported lead receives a new welcome message.
These are the details worth checking before you trust a connection between Local Services Ads and your client management software across your client accounts.
Start with one practical question: can your team follow an inquiry from its Google account to the correct client-system record, responsible person and final outcome? Use the workflow below to evaluate a connector, an automation or a software platform before expanding it.
Define what the integration will actually do
“Connected to Google” can mean several things. A system might retrieve lead records, create contacts in the client system, notify a team, update opportunities or submit lead-quality feedback. Treat each as a separate capability to verify.
Google documents Local Services lead data in the Google Ads application programming interface, including lead identifiers, types, status and credit information. Availability has limitations; for example, healthcare-category lead data is not available through the documented Local Services resources. A documented interface field does not establish that a particular software product uses it. See Google's Local Services resource documentation.
Write down the proposed flow before connecting a client:
- Which supported lead types enter the client system?
- Does the integration create a contact, an opportunity, a task or all three?
- Which system owns the first reply?
- Which changes move back to another system, and which remain local?
- Who sees a failed update, and who fixes it?
Ask the provider to demonstrate the answers for your actual client-system configuration. If a step requires manual work, name it rather than describing the whole workflow as automatic.
Map the client account before mapping the contact
Use the Google customer account and source lead identifier together to identify an inquiry. Google represents a Local Services lead within a customer-specific resource name. Its lead creation time also uses the Google Ads account's timezone. These details matter when mapping clients and comparing timestamps. Review the documented lead fields.
For your own integration design, keep a short mapping record for each business:
- Client business and location.
- Google customer account identifier.
- Intended client-system account or workspace.
- Destination pipeline and initial stage.
- Person responsible for new inquiries.
- Reporting timezone and last successful synchronization.
Have someone verify that record against the intended client before enabling the flow. A business name alone is a weak safeguard when an agency manages similar names or several locations.
Contact matching needs a separate rule. One person might contact a business more than once, inquire about another service or already exist in its client management system. Decide when to attach activity to an existing contact and when to create a new opportunity. Do not equate “same phone number” with “same job.”
Choose one place to record the business outcome
If the client already manages jobs in customer relationship management software, use that workflow as the starting point for outcome collection. Asking an intake team to update a second dashboard creates another place for records to disagree.
A useful agency outcome model can be simple:
- Needs follow-up: someone still owns the next action.
- Booked: the client has confirmed the appointment or job under your agreed definition.
- Not proceeding: the client has confirmed that the opportunity will not move forward.
- Unknown: the outcome has not been verified.
These are suggested internal labels, not a replacement for Google's own statuses. Map them deliberately to the client's existing stages. Keep a separate reason where it helps, such as customer declined or service not offered.
Unknown should never become lost simply because an arbitrary number of days passed. Likewise, a request for an estimate should not become completed revenue because a call summary sounded positive.
Google documents its native Mark Booked workflow for the United States and Canada, and notes that these instructions do not apply to partner-affiliate advertisers. That is distinct from changing a pipeline stage. Ask which action your integration actually performs and how a failed update is shown. Google explains marking leads as booked here.
Keep duplicate events from becoming duplicate work
A retry should not create another opportunity or send another welcome message.
Ask for a controlled demonstration in which the same source event is processed twice. The expected result is one intended record in the client system, with enough activity history to explain the retry. Then test a genuinely new inquiry from the same contact so the duplicate safeguard does not suppress legitimate work.
Deduplicate a repeated delivery, not every later event associated with that lead. Google documents that one lead can have several conversations. A later message or status change must remain visible even when its lead identifier is already known. See the lead-to-conversation relationship.
Synthetic example—not a product demonstration: A demonstration business receives an inquiry that matches an existing contact and creates one opportunity under the agency’s agreed rules. Replaying the same event should not create a second opportunity or send another welcome message. A later message on that inquiry should appear as new activity. If the same person submits a new inquiry for a different job, preserve it rather than suppressing it because the phone number matches. Whether it needs another opportunity depends on the client’s agreed workflow.
Decide how conflicting updates are handled. If an account manager corrects a pipeline stage, should a later synchronization overwrite it? Which timestamp and source determine the current value? Your team should be able to inspect the answer rather than reconstruct it from several inboxes.
Revenue needs the same discipline. Assign a stable job or opportunity identifier, distinguish an estimate from actual revenue, and specify whether your report uses booked, invoiced or collected amounts. Do not add the same job value once from the client system and again from a second imported record. Leave revenue unavailable when it has not been supplied; zero is a different statement.
For the reporting side of this process, use our guide to evaluating Local Services Ads reporting software for agencies.
Separate historical imports from new-lead responses
Importing older records can help establish reporting history. It should not silently start conversations with people who contacted the business months ago.
Before an import, identify every automation triggered by a new contact, pipeline entry, tag or field change. Ask the provider to show a safe import mode with outbound actions disabled, or another documented way to prevent historical records from entering new-lead campaigns.
Then inspect a small, authorized sample. Check timestamps, client mapping, existing-contact matches and whether any notification or reply would fire. Approve the full import only after the sample behaves as intended.
Keep customer data limited to what the workflow needs. Use synthetic records for demonstrations, keep credentials out of email, and have the authorized client approve access and any live communication changes.
Test the handoff before adding more clients
Use a supported test environment or authorized records, rather than creating fake consumer leads through live ads. Ask the person who will own the account to walk through these checks:
- A supported new lead reaches the correct client's system and responsible person. Using authorized synthetic demo records, open the resulting record and any shared output as the intended client role—not an agency administrator—and confirm only permitted data and actions are available. Include an unrelated demo record in the check; a filtered-looking screen alone is not proof of restricted access.
- Reprocessing the same event does not create a duplicate opportunity or reply.
- A later message on the same lead is retained, and a genuinely new inquiry from an existing contact remains visible as new work.
- An outcome correction is retained and appears in the agreed destination.
- A historical import does not activate outbound customer messages.
- A failed connection or update creates a visible issue with a named owner.
- Revenue is counted once, with its source and definition clear.
- Where automated replies are proposed, a human response in the agreed channel transfers ownership as intended. Check whether a pending automated reply is suppressed and what permits automation to resume. If the integration cannot detect that response, document the manual pause procedure and responsible person.
Record the input event, expected record or activity, actual result, timestamp, tester, test role and any manual intervention. For a retry test, record both attempts and the final opportunity count; for a later-message test, confirm the new activity is present. For an import test, retain evidence that no outbound action ran. Use sanitized records, not customer screenshots containing private details.
These are proposed acceptance criteria, not verified LSA Command test results. A successful login is not the same as a passing handoff test. Keep the affected automation paused until the client’s approver accepts a safe result.
Treat self-service setup as a separate acceptance question. If a provider proposes unaided onboarding, have a representative agency owner complete the permitted setup without staff performing steps or explaining missing instructions. Record where help was needed. A working connection demonstrated by an administrator does not establish that an agency owner can set it up independently. This is a suggested evaluation method, not a claim that LSA Command has passed that test.
Start with one representative client, resolve the failures, and repeat the checks when another business has different routing or software requirements. Our multi-account Local Services Ads software guide covers the wider account-by-account rollout.
Explore the connection with LSA Command
The most useful demonstration starts with the handoff your agency needs to improve.
If you want a guided evaluation, book an LSA Command agency walkthrough. Bring the name of your customer relationship management software, client count and a description of one lead-to-booking workflow, without passwords or unnecessary customer details. Ask to verify the supported integration, field mapping, manual steps and test process for that setup before deciding on fit.
A clear demonstration should leave you knowing what works today, what still needs configuration and what your team would own after launch. This invitation is an optional way to evaluate fit, not a statement that a meeting is required to create an account or connect a business. Verify the available setup route before making that decision.