Almost everything I have written on this site is about a lead that never got captured — the call that rang out, the form somebody abandoned at the phone-number field, the quote that went quiet. Multi-location businesses have a different problem, and it is a more frustrating one, because on paper nothing is missing. Every lead is in the system. Every lead has a timestamp. The dashboard is green. And the network is still losing a meaningful share of its inbound demand somewhere between the lead arriving and a human being responsible for it.
That gap is the routing layer, and in most networks it is not a system at all. It is a rule somebody wrote during the second location's opening week, extended informally when the third opened, and never revisited once there were nine. I am Gideon Wafula, an AI automation engineer in Seoul, and this is the failure I see most often once a local business stops being a single location: the capture works, the routing does not, and the reporting is structured in a way that cannot tell the difference.
In a single-location business, capture and ownership are the same event. The phone rings, someone picks it up, and that person now owns the outcome. There is no intermediate state. Add a second location and you have invented one: a lead that exists, is logged, and belongs to nobody yet. That state is where the money goes.
It goes in four fairly distinct ways, and they need different fixes, which is why treating "we lose leads across locations" as one problem produces a build that solves none of them.
The wrong branch. The lead lands with the nearest location by straight-line distance, which is the default in most systems because it is the only field everyone has. Distance is a poor proxy for serviceability. The nearest branch may not cover that side of the river, may not run that service line, may not hold the licence that particular job requires. The lead is not lost yet — but it now has to be noticed as misrouted by someone who has no incentive to look for other people's leads, and then manually moved, which is a step that happens on a good day and not on a busy one.
The shared inbox. The lead routes to a location rather than to a person at that location. A location cannot be held to a response time. Sales@ or the branch mobile is a place where leads are visible to everyone and owned by no one, and the well-documented pattern in shared queues is that response time degrades as the number of people who can see the item increases, because each person reasonably assumes somebody closer to it will take it.
No capacity. The routing is correct, the owner is real, and the branch is booked solid for three weeks. Nothing in the system knows that. The lead sits in a pipeline that looks healthy while the customer, who asked for this week, books the competitor on Tuesday. Meanwhile a branch forty minutes away has open slots and never saw the enquiry.
The handoff between HQ and the location. Marketing runs at the network level, service runs at the location level, and the lead has to cross that boundary. Every crossing is a place where context is dropped — which campaign, what the customer actually asked for, whether they are an existing customer of a different branch. The location receives a name and a number and starts the conversation from zero, which is the same structural mistake I wrote about in the AI-to-human handoff teardown, just happening between two businesses instead of between software and a person.
This is an afternoon of work against exports, and it is worth doing before anyone touches a workflow, because the four failures above have very different sizes in different networks and the fix should be aimed at the biggest one.
Time from lead created to first outbound contact, split by location. Not the network average — the average hides everything. You are looking for the spread. In most networks I have looked at, the gap between the fastest and slowest location is larger than the gap between the network and its competitors, and the slow locations are usually slow for a structural reason (shared inbox, one person covering phones and the counter) rather than a motivational one.
Reassignment rate. How many leads changed owner after creation, and how long they sat before the change. This number sizes the wrong-branch problem directly. It is also usually undercounted, because the informal fix — a manager forwarding it in a group chat — leaves no trace in the CRM at all.
Leads with no outbound attempt in 24 hours, grouped by which inbox they landed in. If these cluster in shared destinations rather than named ones, you have found the ownership problem and you do not need a model to fix it.
Requested timeframe against branch availability at the moment the lead arrived. This one takes the most work to assemble and is the most revealing, because it tells you how much demand the network turned away by silence while holding capacity elsewhere.
Win rate on leads routed correctly the first time versus leads that were reassigned. Expect a real gap. That gap, multiplied by the reassignment rate, is your business case, and it is a defensible number rather than an industry statistic borrowed from a vendor page.
I use n8n for this because it sits between systems that were never designed to talk — a call platform, a form, a CRM, a scheduling tool, sometimes a different scheduling tool per location — and because a franchise network usually needs it self-hosted for data control. The shape is six steps.
Calls, web forms, chat, WhatsApp and marketplace leads land in one intake function and become the same object before anything else happens. This sounds like plumbing and it is the step that makes the rest possible, because routing logic written five times for five channels will drift within a quarter. The object carries: contact details, service address, requested service line, requested timeframe, channel, campaign source, language, and whether this contact already exists anywhere in the network.
This is the unglamorous core of the build and the reason most routing projects fail. For every location you need an honest, maintained answer to three questions: which postcodes or districts it actually services, which service lines it can actually deliver, and what its current capacity looks like. The first two are static and can be written down in an afternoon with the operations lead — the arguments that surface while writing them down are, in my experience, more valuable than the table itself. The third has to be live, pulled from the scheduling system, because a capacity figure typed into a config file is wrong within a week.
Coverage first: eliminate any location that cannot service that address. Capability second: eliminate any that cannot do that job. Capacity third: prefer a location that can meet the requested timeframe. Distance last, as a tiebreaker between locations that passed the first three. Running distance first, which is what most systems do, produces a technically sensible answer that fails on the specifics — and specifics are the entire job.
Route to a human with an on-call schedule behind them, not to a location inbox. If the primary does not acknowledge inside a defined window — I usually start at five minutes during business hours, which is the threshold I unpack in the speed-to-lead post — it escalates to a second name, then to a network-level queue that somebody at HQ genuinely owns. The escalation must be automatic and visible. A chain that only fires when someone remembers to check is not a chain.
The customer should not wait for your internal decision. An immediate message that names the branch that will handle it, the person, and when they will hear back does two things: it holds the lead while routing resolves, and it surfaces misrouting instantly, because a customer told the wrong branch is handling their job will say so. That is free error-checking you cannot buy any other way.
Most builds skip this and it is where the remaining loss concentrates. When no location passes the rules, the system should not queue the lead silently. It should return an honest answer fast: the earliest date anyone in the network can do it, a waitlist entry that fires automatically if a cancellation opens a slot, or a clean referral. Declining quickly costs you one job. Declining after three days of silence costs you the job, the review and any chance of the next one.
These are different views and building one screen for both is a reliable way to get a dashboard nobody opens. The location needs its own leads, its own response times, and its own misroutes — operational, today, actionable. HQ needs the distribution: response time by location, reassignment rate by location pair (which reveals exactly which coverage boundaries are wrong), capacity-driven losses, and leads that fell through to the network queue.
The reassignment-by-pair view is the one that earns its keep. If leads keep moving from location A to location B, your coverage table is wrong on a specific boundary and you can fix it permanently in ten minutes — which is the difference between an automation that works and one that quietly needs a human correcting it forever.
A routing system makes commitments on behalf of locations that did not agree to them. If the automation tells a customer that the Riverside branch will call within the hour, Riverside has to know that promise was made and be able to keep it. Every promise the system makes must correspond to a capability the system verified — otherwise you have built a faster way to disappoint people.
In a franchise network there is also a genuine governance question. Routing rules decide which franchisee gets which lead, which is a revenue allocation decision, and it needs to be explicit and agreed rather than emergent from a config file. Write the rules down in plain language, get them signed off, and log every routing decision with its reason. The log is what settles disputes, and there will be disputes.
On data: this build is entirely inbound and customer-initiated, which is the lightest regulatory position available, but the moment you centralise lead data across locations you have created a single store of customer records that previously lived separately. That is a reasonable thing to do and it changes your obligations — worth a conversation before rather than after.
The running cost sits in the range of 60 to 250 USD per month for a network of a handful of locations, scaling with lead volume rather than location count. The one-time cost is the mapping work, and I would rather someone spend two extra days on the coverage table than any time at all on prompt tuning.
And the honest caveat: routing leads correctly to a location that responds badly does not create revenue, it just relocates the loss and makes it easier to see. If your response-time export shows one branch is slow at everything, the routing build will faithfully deliver more leads into that slowness. Fix the branch, or route around it deliberately, but do not expect the automation to compensate. It is a distribution layer. It cannot do the job.
Gideon Wafula builds custom AI automation systems, n8n, WhatsApp, Voice AI, and more.
See Services →