Articles territories

How a territory dispute is settled, and what it needs from you

Territory disputes turn on a date, a boundary and a rule. Most software can answer one of the three, which is why the argument goes to a spreadsheet.

A territory dispute almost never starts as a dispute. It starts as a question: somebody noticed a customer they thought was theirs, and they want to know what happened. How that question gets answered in the next ten minutes decides whether it stays a question.

The shape of the question

Strip out the frustration and every one of these reduces to the same three parts.

A date. Not today. The day the enquiry came in, the day the job was booked, the day the contract was signed. Territory questions are always historical, because nobody disputes something that has not happened yet.

A boundary. Whether that address was inside a particular area, as that area was defined on that date.

A rule. If it was inside more than one, what decided.

Most territory software can answer the boundary part for today. That is one third of one question, and it is the third nobody was really asking.

Why “here is the current map” makes it worse

Showing somebody today’s map in answer to a question about March does two things, and both of them are bad.

It does not answer the question, which is obvious to everyone in the room.

And it invites the suspicion that the map changed. If you cannot show what the boundary was, you cannot show that it did not move, and a person who believes they lost a customer is already looking for a reason. The absence of a record reads as a missing record rather than as a record that was never kept.

What has to exist before the argument starts

Versions that persist. Every published configuration is kept, with the dates it was live. A rollback is choosing an older version, not editing the current one back into shape from memory. This is the piece that turns a dated question into an answerable one, and it has to be there before the dispute, which is why it is easy to skip.

A recorded decision, not a reconstructable one. There is a difference between being able to work out what the answer would have been and having the answer that was given. Reconstruction runs today’s code over yesterday’s data and produces something plausible. What ends an argument is the response the system actually returned at the time, with its reason.

A rule with an author and a date. “Territory priority put the metro franchise ahead of the regional one, under the rule published on 3 March” is a sentence somebody can accept or challenge. “The system assigned it” is not a sentence about anything.

A change history. Who edited the boundary, when, and what it was before. Most disputes that are really about a change turn out to be about a change somebody made for a good reason and told nobody about.

The four disputes that actually happen

Two people quoted the same job. Almost always an overlap nobody knew about, created when two territories were drawn a year apart by different people. The fix is not to pick a winner; it is to notice the overlap exists and decide, once, which rule governs it.

A lead went somewhere else. Usually correct and unexplained. Somebody was excluded by a rule, or a capability check, or an out-of-hours fallback. All defensible, none visible.

The boundary is not what the contract says. The agreement names three counties, the map was drawn from a radius, and they disagree along one edge. A real conflict, and the software’s only job is to surface it early rather than let it be discovered by a customer.

Volume dropped after a change. Somebody adjusted a boundary to fix a different problem and did not realise whose leads they were moving. The change was reasonable. The way it happened was not, and that is a process problem a change history makes visible.

What this costs you if you do not have it

Not the disputes. Disputes happen anyway, in every network, and most of them are misunderstandings that resolve in a sentence when the sentence is available.

What it costs is that each one becomes an investigation. Somebody exports a spreadsheet, somebody else remembers what the map used to look like, and the answer arrives two days later carrying less authority than it should, because it was assembled by an interested party after the fact.

The version history is what makes the answer boring. Boring is the goal.

Related: what a version has to record, and why overlaps are worth keeping.