Lead routing inside one company is an efficiency question. If an enquiry goes to the wrong branch, somebody forwards it and the day continues. Inside a franchise network the same mistake is a different kind of event, because the territory is something a franchisee paid for, and a lead that went elsewhere looks like a breach of the thing they bought.
That difference should change what the software does, and usually it does not.
The three questions a franchisee actually asks
Not “where did this lead go”. They ask:
- Was this address in my territory? A yes or no about a boundary on a specific date.
- If it was, why did somebody else get it? There is often a legitimate answer, and it needs to be sayable.
- Who decided that, and when? Because if the answer is “the software”, the conversation is over and the relationship is worse.
Software that can answer the first question and not the other two is what franchise operations teams usually have. It is enough to run the network and not enough to settle an argument, which means every argument escalates to a person with a spreadsheet.
Why “the system assigned it” is not an answer
A routing decision inside a franchise network has to survive being read by somebody who did not make it and has money riding on it. That rules out a few common designs.
Ordering that is not written down. If two territories both cover an address and the winner is whichever row the query returned first, there is no answer to question two. The behaviour may be perfectly stable and it is still not a rule, because nobody agreed to it and nobody can quote it.
Rules that live in a workflow tool. Routing built out of if-then steps in a CRM is a rule in the sense that it executes. It is not a rule anybody can read: tracing why one branch won means opening the automation and replaying it in your head, and only the person who built it can do that.
A decision with no trace. Even a correct answer is unusable in a dispute if the only record is that the lead exists on somebody’s queue. What settles the argument is the list of territories that contained the address, the rule that picked between them, and the version of the map that was live when it happened.
What good looks like
Overlap is representable. Networks that grew by acquisition have overlapping coverage, and territories that were sold at different times with different maps. Software that refuses to store an overlap forces somebody to redraw the map to fit the tool, which means changing what franchisees own to make a database happy.
Priority is a rule somebody wrote. When two territories cover an address, what decides is an explicit rule with an owner and a date: a layer order, a priority number, a named exception. It should be quotable in a sentence, because that is the sentence that ends the phone call.
The map is versioned. Territory questions are dated. “Who owned this postcode in March” is answerable only if March’s map still exists. This is the single biggest gap between territory software and a spreadsheet, and it is invisible until the first dispute.
Every decision explains itself at the time. Not a log somebody reconstructs later, when the map has moved on. The answer and the reason are the same object.
The cases that come up in practice
A national account with local delivery. The customer is signed centrally and served in twelve territories. The routing question is not who owns the address, it is which agreement applies, and the map has to be able to say both.
A territory sold before it was drawn. The agreement says three counties. The map says a boundary that includes half of a fourth, because somebody drew it from a radius. Which is right is a legal question, and the software’s job is to make the disagreement visible rather than to pick a side quietly.
A franchisee who cannot take the work. They own the territory and they are not certified for this service, or they are at capacity. Routing to them is correct and useless, and routing past them without saying so is how the first kind of dispute starts. The fallback has to be a rule too.
The part that is not software
None of this decides who should own a territory, what happens when one is underperforming, or how to price the next one. Those are commercial negotiations, and a tool that offered an opinion would be answering a question nobody asked it.
What software can do is make sure that when the negotiation happens, everybody is arguing about the same facts. That turns out to be most of the problem.
If territories in your network are contested, the two things worth reading next are how a territory dispute is actually settled and what a version has to record for that to be possible.