Local lead routing fails quietly. A form may submit successfully, a CRM record may exist, and a notification may be sent while the inquiry reaches the wrong location or nobody owns the next step. Good routing starts with service eligibility and identity, then makes assignment, response, exception and audit rules explicit.
1. Define the routing decision
Write what the rule must decide: location, service team, territory, queue, owner, priority or fallback. Define what counts as a valid lead and what happens when the visitor is outside the service area, requests several locations, or does not provide enough information.
Separate location assignment from lead qualification. A lead can belong to a branch even when it is not sales-ready. Mixing the two decisions creates false zeros for a location and hides the reason a record was not accepted.
2. Establish a location and service registry
Give each location a stable internal ID and map it to profile ID, website page, phone number, form, service area, CRM value, owner, backup owner, timezone and operating hours. Record which services each location can actually deliver.
Google’s Business Profile representation guidelines require a business to represent its real-world location or service area accurately. Use that principle in the routing registry: do not create a route for a virtual branch or promise a service that the location cannot fulfil.
Version the registry when a location opens, closes, moves, changes service coverage or shares a central team. Never reuse a historical location ID for a new operating unit.
3. Design the intake fields
Identify the minimum fields needed for routing: requested location, service, postal code or city, contact preference, source, consent, urgency and language where relevant. Keep raw input and normalized values separately. Define allowed values, unknown paths and validation messages.
Do not make every field mandatory if a missing value can be resolved by a human. Instead, route incomplete records to an exception queue with a clear owner and service-level expectation. A blocked form can be worse than a transparent exception.
4. Define priority and ownership
Write the order of routing rules and the owner for each outcome. Decide whether the record goes to a person, queue, round-robin, branch inbox or central team. Define backup ownership for holidays, after-hours and absence, and record when an assignment is considered accepted.
Salesforce’s assignment-rule guidance describes rules that assign leads to users or queues based on criteria. The exact platform differs, but the governance questions remain: what fields are evaluated, in what order, and who owns an exception?
5. Test identity across channels
Trace website forms, click-to-call, tracked calls, booking links, local profiles, chat and manual imports. Confirm that the location ID survives redirects, transfers, duplicate submissions and CRM conversion. For a central phone line, preserve the originating location and the final service team.
Use synthetic records with explicit location and service values. Include a missing location, an invalid service, two requested locations, a transfer and a duplicate. Record expected route, actual route, notification, response owner and downstream stage.
6. Build the response and escalation path
Define first-touch expectation, business-hours behavior, after-hours message, retry limit, escalation owner and customer-facing promise. A routing rule is incomplete if the assigned user cannot see why the record was routed or what to do next.
Measure assigned, accepted, contacted, qualified, booked and closed outcomes separately. Keep unassigned, duplicate, spam, out-of-area and capacity-blocked records visible. Do not call an uncontacted record a lost lead without a documented attempt policy.
7. Govern changes and exceptions
Keep a rule register with rule ID, condition, priority, owner, effective date, source field, destination, notification, exception queue, test record and rollback. Require review when a location, service, form, phone number, CRM field or ownership model changes.
Google’s Business Profile service-area guidance explains that service areas should reflect where the business can provide products or services. When coverage changes, update both the public representation and the internal routing registry through the same controlled change record.
8. Use a governance checklist
| Check | Pass evidence | Hold condition | | — | — | — | | identity | stable location and service IDs | duplicate or reused ID | | eligibility | service-area and capability confirmed | route promises unavailable service | | intake | fields, validation and unknown path defined | free text drives assignment | | priority | ordered rules and owner documented | rules overlap without precedence | | response | acceptance, fallback and escalation named | notification has no owner | | quality | synthetic cases cover missing and duplicate data | only happy path tested | | audit | change log and rule version stored | edits are invisible | | rollback | prior rule and queue can be restored | no safe pause path |
Attach the registry, rule table, test evidence, exception report and approval owner to the release record.
Review the checklist after every material change to service coverage or ownership. A routing rule that was correct last quarter can become unsafe when opening hours, staffing or branch capability changes.
9. Pilot one location and one fallback
Select one representative location and one central fallback queue. Test every important intake path with synthetic records, observe normal processing, review response ownership and reconcile CRM outcomes. Keep current routing unchanged while the pilot runs, and define a stop condition for misroutes or missing notifications.
Scale only after the pilot explains both successful assignments and exceptions. This article remains a local draft until overlap, platform, privacy, local-policy and prepublication review are complete; no routing, profile or CRM rule is changed by the checklist.
How did this article land?
Choose one reaction. You can change it anytime.