A customer types an address, and the answer is no. Before touching the map, read the reason code: the API returns one with every decision, and the four kinds of no have four different fixes. Changing territories to fix a rule problem, or rules to fix a geocoding problem, leaves you with two problems.
NO_TERRITORY_COVERS_POINT: the address is outside every shape
The point landed on the map and nothing covers it. Three usual causes, in order of frequency:
- The territory really does not cover it. Open the territories page, paste the coordinate from the decision into the playground, and look. ZIP boundaries in particular are smaller than people remember them, and a customer just over the line is over the line.
- You drew from ZIPs and the address sits in a ZIP you did not list. ZIPs are not exhaustive tilings; a new development can carry a code your list predates. Rebuild the territory with the missing ZIP added.
- The published version is older than your edits. Drafts do nothing until published. The territories page banner says which draft is open; the decision says which version answered.
ALL_CANDIDATES_INELIGIBLE: covered, but nobody can do the work
A territory covers the point, and every location it assigns fails an eligibility test: the service was not offered, the location is archived, a rule excluded it. The decision’s trace lists each candidate and the exact rule that eliminated it. Fix the losing condition, not the geometry: the shape is right.
The commonest version is a service mismatch. The request asked for
plumbing, the covering location offers hvac, and the honest answer is
exactly what the customer was told. Add the capability on the locations
page if the location really does the work.
EXCLUDED_BY_RULE: a rule you wrote said no
A rule matched and its outcome was exclusion. The trace names the rule. If the exclusion is wrong, edit that rule in the draft, run your saved test cases, and publish. If you find yourself deleting a rule you do not recognise, check the audit log first: it says who added it and when, and a rule somebody added deliberately usually has a reason worth knowing before it goes.
ADDRESS_NOT_FOUND and ADDRESS_TOO_IMPRECISE: the no happened before the map
No geocoder could place the address, or could only place it to a town or a postal code, which is not precise enough to route on. This is not a coverage answer and the API deliberately does not pretend it is. The fixes live on the input side: ask for the city and state, not just a street line, or accept a coordinate directly where you already have one. A point you supply is used exactly as given, which also makes the decision reproducible.
When the answer is right and the customer is still upset
Sometimes the configuration is correct and the business answer is the problem: the customer is genuinely outside the area. The widget can say something useful there, with its own wording and a link for the not-covered case, so a no becomes a waiting-list signup instead of a dead end.