On this page
Most multi-location problems do not start as technology problems. They start the day someone copies the setup from the first branch into the second one because it is faster than thinking it through. The AI answers just as quickly in the new market, but it quotes the wrong diagnostic fee, accepts a job type that branch does not run, and tells a customer forty minutes outside the coverage area that a technician can be there today.
Configuring AI lead response across branches is an operations exercise before it is a software exercise. This is the sequence I use when a company goes from one location to several, or when an agency inherits an account with six markets already running.
Why one shared setup breaks at the second branch
A single-location business hides an enormous amount of context inside people's heads. The dispatcher knows which suburbs are too far, which technician handles commercial work, and that the Tuesday promotion never applied to the north side. None of that is written down, and none of it is portable.
When you clone the configuration, you clone the assumptions with it. The errors that follow are predictable: quoted prices that do not exist in that market, service promises for work the branch does not perform, coverage that spills into a franchise partner's territory, and two locations both replying to the same customer.
These are not conversational failures. The AI is doing exactly what it was told. The instructions were simply written for a different business.
Define what a location actually is
Before you configure anything, agree on the unit. On our pricing page, a location is defined as each unique service area with its own team, phone number, or Google Business Profile. That is a useful operating definition well beyond billing, because those three things are exactly what create divergent rules.
Two crews working out of one building under one number are one location. One brand running Phoenix and Tucson with separate teams and separate Google profiles is two. A satellite van parked in a neighboring county with no separate number or team is usually a coverage extension of an existing location, not a new one.
Write this into a source-of-truth location record before touching the AI. At minimum it should hold: location name and internal code, service area definition, phone number, Google Business Profile, service list, exclusions, hours, price references, escalation contacts, and the person accountable for keeping it current. Keep it in one place that everyone edits, not in a chat thread.
Separate brand rules from location rules
Split your instructions into two layers and never mix them.
Brand rules are the things that must be identical everywhere: tone, greeting structure, how you ask for an address, privacy behavior, what the AI never promises, how it hands off to a human, and how it treats spam or non-service inquiries.
Location rules are the things that must differ: services offered, work explicitly excluded, coverage boundaries, hours, holiday closures, price references, escalation contacts, and capacity limits.
The practical test is simple. If changing the value in one market would be a mistake everywhere else, it is a location rule. If you find yourself pasting a market-specific number into a brand-level instruction, stop. That is how the wrong price reaches the wrong customer. The AI customization layer exists for exactly this separation, so use it rather than maintaining seven near-identical copies of one script.
Configure services, exclusions, and coverage per branch
For each location, answer four questions in writing.
What do we sell here? List the actual job types this branch performs, not the corporate service menu. If the Denver branch does residential only, residential only is the list.
What do we refuse here? Exclusions matter more than inclusions. Commercial work, warranty jobs on brands you no longer service, new construction, anything requiring equipment this branch does not own. If it is not written as excluded, someone will eventually book it.
Where do we go? Define coverage in the form your team actually uses: ZIP list, radius from the shop, or named municipalities. ZIP lists are the least ambiguous and the easiest to test. Radius rules are convenient but produce absurd results across rivers, mountains, and toll bridges.
What happens in the overlap? Adjacent branches will share ZIPs. Decide the tiebreaker in advance: nearest shop, primary owner of that ZIP, capacity that day, or job type. Write the rule once, apply it consistently, and revisit it when territories change.
Keep the coverage in your ad platforms consistent with this record. Google's guidance on editing your ad or business information covers updating service areas, categories, and hours on the profile itself, and the broader Local Services help center is the reference for how those settings affect the leads you receive. If the profile says you cover a county but the AI declines it, you paid for a lead you then turned away. Fix the mismatch in both systems, not one.
Price rules belong to the location, always
This is the rule I am strictest about: a branch may only quote its own numbers. Never let the AI infer, average, or borrow a price from a sibling location.
For each location maintain the diagnostic or trip fee, whether it is waived on repair, the estimate policy for the job types that branch runs, any active discounts with start and end dates, and any market-specific charges your finance team applies. If a number is not confirmed for that branch, the correct behavior is to say a team member will confirm pricing, not to produce a plausible figure.
Talk to your accountant about how taxes and surcharges should be presented in each market. That is their call, not a configuration guess.
Hours, holidays, and capacity by market
Hours vary more than people expect: seasonal Saturdays in one market, an earlier close in another, different regional holidays. Set them per location, including holiday closures for the next twelve months, and define what after-hours means for that branch specifically.
Capacity is the setting most teams forget. If a branch runs three trucks, the AI should not be describing same-day availability at four in the afternoon in peak season. Give each location an honest statement of what it can commit to and let the human team confirm the actual slot.
Decide lead ownership before you automate
Every conversation needs exactly one owning location. Decide this before launch, not during the first territory dispute.
Set the assignment rule (usually the ZIP owner, or the branch tied to the phone number or profile the lead came through), then define the transfer path: who initiates it, what gets communicated to the customer, and how the receiving branch picks up the context. A transfer should read as one company handing a customer forward, not as the customer starting over.
Also decide the duplicate rule. When the same customer contacts two branches, one owns the thread and the other stands down.
Escalation and unavailability per branch
Name the escalation contacts for each location by role, not just by person: who handles urgent jobs, who handles pricing exceptions, who handles complaints. Then answer the harder question, which is what happens when nobody at that branch is available.
The acceptable answers are a defined backup contact, a regional or corporate desk, or an honest acknowledgement with a commitment to follow up. The unacceptable answer is silence. Set this explicitly for every location, because the branch with the thinnest coverage is the one where it will matter.
One brand voice, local specifics
Consistency of voice does not require identical wording. Keep the greeting, the structure of questions, the level of formality, and the handoff language the same everywhere. Allow local variation in the service vocabulary customers actually use, seasonal context, and the expectations that market has around scheduling.
A customer who moves between two of your markets should recognize the same company. They should not receive the same brochure written for somewhere else.
Track outcomes by location, and control changes
Review each location on its own. Look at response times, how many conversations reached qualification, how many were handed to the local team, and where conversations stalled. Comparing branches to each other surfaces configuration problems faster than any single aggregate number, and the product overview and Google LSA integration pages describe what is available in the dashboard for that review.
Then govern the changes. Name who may edit location rules, require an effective date on pricing and coverage changes, and review any change that affects a shared boundary with both branches present. Keep a short log of what changed and when, because when a bad quote surfaces three weeks later, the log is how you find the cause in minutes instead of days.
Test before you launch a market
Run these scenarios per location, with real inputs:
- A boundary ZIP just inside coverage, and one just outside
- A ZIP claimed by two branches
- An excluded job type
- A request while the branch is closed, and on a holiday
- A price question for a service that branch does not offer
- An urgent request when the local escalation contact is unavailable
- A transfer between two branches
If any scenario produces a promise the branch cannot keep, fix the rule and rerun it.
Launch checklist
- Location record complete and owned by a named person
- Brand rules and location rules separated
- Services, exclusions, and coverage confirmed per branch
- Prices, fees, and discounts confirmed per branch, with no borrowed numbers
- Hours, holidays, and capacity set per branch
- Ownership, overlap, and transfer rules written
- Escalation contacts and unavailability fallback named
- Ad platform service areas and hours matched to the record
- All test scenarios passed
- Change-control owner and review cadence agreed
The short version
Multi-location AI lead response works when each branch is configured as the business it actually is, under one brand standard. Define the location, write its rules down, forbid borrowed prices, decide ownership before the first overlap, and test the edges. The configuration effort is a few hours per market. The alternative is discovering the gaps one wrong quote at a time.