Point in polygon is a solved problem. Any competent developer can implement it in an afternoon, and a dozen APIs will do it for you. So the natural conclusion, when somebody needs territories, is that a geofencing API plus a little glue will do.
It usually will, for about a quarter. Here is what the other three quarters turn out to be.
What geofencing gives you
A shape, a point, and an answer about containment. Some services add a spatial index so the query is fast over many shapes, and some add entry and exit events for a moving device.
That is the correct scope for what it is, and it is genuinely the hard part of the geometry. The problem is that containment is one stage of a decision, and in practice it is the stage nobody argues about.
What is left over
Several shapes contain the point. This happens immediately in any real network: sales areas and service areas overlap by design, acquisitions leave duplicates, a metro area sits inside a regional one. Containment returns a set. Something has to pick, and that something is a rule with an owner, not a tiebreak in your query.
The winner cannot do the job. The territory covers the address and the branch does not do gas work, or is closed, or is at capacity. Geography was never the whole question, and a system that answers it as if it were produces dispatches that fail later.
The address is not a point yet. Customers give you an address. Turning it into coordinates is a separate system with its own failure modes, and the most important thing it returns is not the point but how confident it is about it. See geocoding precision.
The map changes. Boundaries move. Six weeks later somebody asks what the answer was in March, and a service that stores the current shapes has no way to say. See what a version has to record.
Somebody has to explain the answer. A boolean cannot be defended. When two partners disagree about who should have got an enquiry, what settles it is which areas contained the address, which rule chose, and under which version.
Somebody has to edit the shapes. Not a developer. The person who knows the territories is in operations, and they need to draw, import, see overlaps and publish without opening a code editor.
The honest build estimate
The geometry is a week. The rest is the year:
- A rule model that is expressive enough to be useful and constrained enough that nobody can write an infinite loop into your routing.
- Versioning, drafts, and an atomic publish, so a customer is never answered from a half-finished map.
- A decision trace, stored, so support has something to read.
- Geocoding with precision reported honestly rather than a point for everything.
- An editor, an importer, and overlap and gap detection.
- Per-tenant isolation, if your own customers each have their own map.
Every one of those is a thing somebody has asked for after the geofences worked.
When a geofencing API is the right answer
Genuinely often. If the shapes do not overlap, do not change, and the answer is consumed by one system that does not have to justify it to anybody, then containment is the whole problem and anything more is overhead.
Delivery radius on a menu page. A single service area on a marketing site. Whether a device left a site. All of these are containment questions and adding a rules engine to them makes them worse.
Where the line is
The moment a second person has an opinion about the answer, the shape is no longer the problem. Two territories that overlap, a partner who lost a lead, a franchisee reading a contract, an operations manager who moved a boundary without telling anybody: all of those need a decision that carries its reasoning and a map that remembers what it used to be.
That is not a geofence with extra features. It is a different thing that happens to contain one.