Franchise networks
When a territory is a contract, the map needs a history
Franchise boundaries are not an operational preference. They are what a franchisee bought, and the questions that matter about them are dated: who owned this ZIP code in March, who changed it, and what the system told the customer at the time.
The three arguments
- Two franchisees, one address
- Boundaries drawn at different times by different people, and nobody notices until both quote the same job. The argument that follows is about what the agreement says, not about software.
- Nobody can say what the boundary was
- A dispute is about a date: who owned this ZIP code when the inquiry came in. If the map only holds today, the honest answer is that nobody knows.
- A change nobody agreed to
- Somebody edits a territory to fix a problem, and a franchisee finds out when their lead volume drops. The edit was reasonable; the way it happened was not.
Every map is a version, and versions do not disappear
Changes are made in a draft and published as a version. The published one is what answers every request, the previous ones stay readable, and a rollback is choosing an older version rather than editing today's map back into shape from memory.
That is what makes a dated question answerable. When a franchisee asks who owned an address in March, the answer is the version that was live in March, and the decision the system actually returned at the time.
A territory exhibit you can print
From any published territory, the app prepares a printable exhibit for an agreement or a dispute, showing the territory as it stands now or as it stood at a date and time you choose. It prints on US Letter from your browser, and Save as PDF gives you a file.
It carries the organization and territory names, who serves it, a map of the boundary, and the ZIP codes or counties it was built from when it was built from a list in the app. Otherwise it gives the boundary's extent and point count. It names the configuration version that was live at that moment, when it was published and by whom, and the territory's change history up to that date.
The boundary itself goes with it as a GeoJSON file, and the exhibit prints the file's SHA-256 fingerprint, so anyone can check that the file they were sent is the one the page describes. It is a record of what the system held, starting from your first publish here. It is not a survey and not legal advice.
Overlap is allowed, and then resolved out loud
Networks that have grown by acquisition have overlapping coverage, and software that refuses to represent that forces somebody to redraw the map to fit the tool. Territories may overlap here. What decides who wins is a priority rule somebody at head office wrote and can change, and the decision says which rule applied.
The difference matters in a dispute. "The system assigned it" is not an answer. "Territory priority put the metro franchise ahead of the regional one, under the rule published on 3 March" is.
What it does not do
It does not hold your franchise agreements or calculate royalties. It answers where the boundary is and who it belongs to, which is one input to those systems rather than a replacement for them.
It does not decide who should own a territory. That is a commercial negotiation, and a tool that offered an opinion on it would be answering a question nobody asked it.