How to route inquiries to the right location without losing the whole picture

An inquiry arrives at 7:48pm through the form on your main website. The person types a ZIP code, picks a service, and leaves the location dropdown untouched because nothing told her it mattered. That submission now has to reach one of your four sites, and nothing in your setup knows which one. So it sits in a shared inbox until someone at head office forwards it the next morning, lands at the wrong branch, and gets forwarded again. By the time the right team sees it she has booked with a competitor. Nobody records it as a lost lead, because nobody recorded it at all.

What a misrouted inquiry actually costs you

Routing failures in a multi-site business rarely announce themselves. They show up as a slow month at one branch and a stretched rota at another, and both get explained away as local market conditions. The leaks are specific, and all of them are invisible from the center.

• The misrouted lead. An inquiry that reaches the wrong site is usually dead by the time it reaches the right one, and it never enters anyone's pipeline, so it never appears in a report.
• The double-contacted lead. Two branches work the same prospect because neither knew the other had it. The prospect notices and draws the obvious conclusion about how organized you are.
• The unowned lead. In a shared pipeline, an opportunity with no named owner belongs to everyone and therefore to nobody. It sits in the first stage until someone archives it.
• The capacity mismatch. One site turns work away while another has empty slots, and the routing has no idea, because it was built on geography rather than on availability.

Then there is the reporting failure, which compounds. Head office wants leads, bookings, speed to lead and close rate per site, comparable. What it gets is four spreadsheets with four definitions, assembled late, by hand, by someone who then has to defend the numbers in a meeting.

The real problem is that your records have no location

Almost every multi-site routing problem traces back to one structural gap: location is not a field on the record. It lives in a form notification, in a phone transfer, in somebody's memory, or in whichever inbox the message happened to land. Because it is not a field, it cannot be used to route, to filter permissions, to segment reporting, or to audit a mistake after the fact.

Everything downstream inherits that gap. You cannot give a branch manager their own dashboard if the records do not know which branch they belong to. You cannot stop two sites working the same lead if there is no owner field to check. You cannot tell whether your routing is accurate, because there is nothing to compare the final location against. Businesses in this position usually buy more tools, when what they need is one mandatory field and a documented order of precedence for filling it in.

Head office wants one view and managers want privacy. Both are reasonable.

The two requirements sound contradictory. Head office wants everything in one place with consistent definitions. Each location manager wants their own data, their own team and their own pipeline, with no visibility into a neighbor's performance or a neighbor's customers. That second requirement is partly a trust matter and often a data protection one, because staff at one site browsing another site's customer records is an access control problem under most privacy regimes.

They are not contradictory. One data model with a mandatory location field, a permission layer that filters on it, and reporting that aggregates above the filter satisfies both at once. Managers see a filtered slice. Head office reports across the slices. Nobody assembles a spreadsheet. If you want the full field list, pipeline design and permission matrix, that is set out in the multi-location routing and reporting build.

What good multi-location routing looks like

1. Every contact, opportunity, appointment, form submission and conversation carries a location from the moment it exists. There is no bucket of unassigned leads, because unrouted is an alert state rather than a resting place.
2. Routing follows a documented order of confidence rather than a receptionist's judgment, and the system records which mechanism assigned the location.
3. Inferred routing says so out loud. When location was guessed rather than chosen, the first message confirms it, which turns a potential misroute into a one-line correction from the customer.
4. Every lead has one named owner at one site, assigned after a duplicate check rather than before it.
5. Transfers are a workflow with a required reason and an audit trail, not an edited field. The sending site keeps a visible transferred-out record, so no funnel quietly improves by losing leads.
6. Every outbound message sends from the assigned location's own number, so replies land with the team that owns the lead.
7. Opening a new site is a provisioning routine measured in days, not a rebuild.

How to set up location routing, step by step

Step 1: Freeze the location list and give each site a short code

Decide the codes before anything is built and never reuse one for a different site. Use short codes rather than display names, so a rebrand does not break every filter and every report. Renaming a location later is cosmetic. Recoding one destroys your history.

Step 2: Make location mandatory on every record type

Not just contacts. Opportunities, appointments, tasks, conversations and form submissions all need it. Alongside it, store how the location was assigned, how confident that assignment is, and what the previous location was if the record has moved. Those three extra fields are what let you audit routing later instead of arguing about it.

Step 3: Build the territory table as data, not as automation

Map ZIP code or zip prefixes to location codes in an editable table that a manager can maintain without touching workflows. Handle overlaps explicitly by naming a primary and a secondary site rather than splitting a prefix. Expect two or three sessions of argument about border areas, and get the managers who will live with it to sign it off. This is the single most underestimated task in the whole project.

Step 4: Rank your routing signals by confidence

Evaluate mechanisms in strict order and stop at the first that resolves. An explicit choice on the form beats everything, so make that field required and prominent. Then a dedicated inbound number or location-specific form, which needs no inference at all. Then page and campaign context. Then the territory table. Round-robin is a last resort, used only across sites with open capacity, and always flagged as a fallback so the first message asks rather than assumes.

Step 5: Replicate one pipeline per site instead of sharing one

Identical stage names and identical stage-entry criteria, copied per location. Identical stages are what make the roll-up possible. Separate pipelines are what make the permissions clean. Add a terminal transferred-out stage so a lead that moves sites does not vanish from the sending site's funnel without explanation, and keep a central exceptions pipeline for out-of-area and multi-location inquiries.

Step 6: Make transfers a workflow, not an edit

A staff member requests a transfer, gives a reason, and the workflow does the rest: it stamps the previous location, opens a fresh opportunity at the receiving site with the full conversation history and the original campaign intact, assigns a new owner, notifies both teams, and closes the old owner's task so nobody works a lead they no longer own.

Step 7: Apply the permission filter to all six surfaces

Pipeline views, calendar views, contact search, exports and saved reports, notification routing, and conversation inboxes. Most builds secure the first two and leak through the other four. Test it by logging in as a real location user and deliberately trying to find a contact you know exists at another site. Repeat that test after every configuration change and every new site you open.

Mistakes that quietly wreck multi-location reporting

Mistake 1: Letting each site keep its own pipeline stages

One manager insists their site needs an extra stage, and the roll-up report dies. Differences between sites stop being real and become definitional. This has to be settled by the owner before launch, not negotiated site by site afterwards.

Mistake 2: Routing on geography alone

ZIP code is a good signal and a bad sole signal. It ignores which services a site actually offers and whether it has any capacity. Check the service-by-location matrix and the capacity flag before you commit the assignment, or you will book a customer into a site that cannot serve them.

Mistake 3: Sending every notification to one central channel

This destroys the model on day one. If head office sees every alert, head office becomes the router again. Every workflow notification should address the named owner or the location's own channel, and a response-time breach at one site should wake that site's manager rather than the group.

Mistake 4: Letting staff fix routing by editing the field

A silent edit leaves no reason, no audit trail and no closed task at the sending site. Within a quarter nobody can explain why transfers between two sites run one way, and the fix becomes guesswork instead of a correction to the territory table.

Mistake 5: Treating an opt-out as belonging to one number

If each site has its own number and suppression is per number, a customer who stops messages from one branch starts receiving them from another. Apply a brand-level do-not-message flag that every workflow checks, and test it by opting out on one number and attempting a send from a different one. Messaging rules vary by jurisdiction, so confirm the specifics with your own counsel.

How to measure whether your routing is actually working

Multi-site reporting is only worth building if you watch a small number of honest numbers. These are the ones that tell you something you can act on.

• Routing accuracy: the share of leads whose final location equals their first assigned location. This is the headline number. Watch it weekly for the first two months and expect it to climb as the territory table matures.
• Confidence distribution: how many leads were routed on an explicit choice versus an inference versus a fallback. Raising the explicit share by making the location picker required is the cheapest accuracy improvement available.
• Reassignment rate, and the direction of transfers between each pair of sites. A persistent one-way flow is a table error with a specific fix, not customer indecision.
• Speed to first contact, median and ninetieth percentile, per site and per hour of day. The median will look fine while a fifth of your leads wait an hour.
• Unrouted dwell time, which should be measured in seconds. Anything lingering means a routing mechanism failed silently.
• Duplicate-across-site rate, where the target is zero.
• The per-site conversion ladder from contact to booking to show to close, compared like for like. Because the stages are identical by construction, the differences are real.
• Capacity utilization and overflow volume per site. Sustained overflow at one site is a hiring decision; sustained slack at another is a marketing allocation decision.

Capture baselines before you change anything: current speed to lead per site and current conversion per site, however rough. Without them the first month of comparisons proves nothing. If routing by territory is the part you most need to get right, the territory-based lead routing build covers the table design in more depth, and you can book a call to work through your own site list and corporate structure before anything gets built.

Frequently Asked Questions

Should each location have its own phone number?

Yes, one local number per site, and it is close to non-negotiable. A local number lifts answer rates, and more importantly it means a reply lands with the team that owns the lead rather than in a central inbox. Keep one additional brand number for the inbound menu and voice routing. Register every number under the same messaging campaign and add new ones as sites open.

Can location managers see each other's data?

That is a deliberate choice rather than a technical limitation, and the sensible default is no. Managers see their own site and their own team. Head office sees the roll-up. Whether to publish a cross-site league table is a culture decision with real consequences either way, so it should be the owner's explicit call rather than an accident of configuration.

What happens to a lead when a customer names a different branch?

It should trigger a transfer workflow rather than an edit. The record keeps its original source and campaign, the receiving site gets the full conversation history and a new owner, the sending site keeps a transferred-out record, and the reason is stored. That way attribution survives the move and the pattern of transfers becomes data you can fix.

How long does this take to set up?

Expect several weeks rather than several days, and pilot two sites before rolling out to all of them. Choose two with a contested border, because that is exactly where the routing will fail. Run the pilot for about a month, measure routing accuracy, fix the territory table, then extend. Migrating historical records with the location field populated matters too, or your first month of comparisons is meaningless.