Every tool in this category will draw a shape on a map and tell you whether an address is inside it. That is table stakes and it is not what separates them, which makes the category hard to buy in. Here are the questions that do separate them, in the order they will bite you.
Can it say no?
The most useful thing a service area system produces is a refusal. An address outside every area, or inside one nobody can serve, is a fact you need: it is a customer to be told honestly, and it is a data point about where demand exists and coverage does not.
Systems tuned to assign everything have a perfect assignment rate and no idea where their gaps are. Ask what happens to an address in the middle of nowhere, and be suspicious of a demo where everything gets an answer.
Does it know what each location can do?
Coverage and capability are different. A branch twenty minutes away that does not do gas work is the wrong answer, and if the system only models geography then somebody in dispatch is fixing it by hand every day.
Ask whether a location carries what it can actually do, and whether that filters candidates before an assignment is made rather than after.
Does it tell you how well it found the address?
Every geocoder returns coordinates. Some of those coordinates are a building and some are the middle of a postal area, and a system that does not distinguish them will hand you confident wrong answers with no way to spot them.
Ask what precision comes back with a decision, and what the system does with a partial match. “It always returns something” is the wrong answer. See geocoding precision.
Can it answer a question about last quarter?
Boundaries change. When somebody asks what the system said in March, either March’s map exists or it does not, and the second case turns every historical question into an argument.
Ask whether a change creates a version, whether old versions stay readable, and whether the decision itself was recorded or would be recomputed from today’s map. See what a version has to record.
Can somebody in operations change it?
The person who knows the service areas is not the person who can deploy. If adding a boundary means a ticket, the map goes stale, and a stale map is worse than a coarse one because everyone still believes it.
Ask who can publish a change, how long it takes, and what stops a half-finished edit from answering live requests.
Can the answer be shown to somebody who disagrees?
At some point two people will want different answers for the same address. What ends that conversation is a decision that carries its reasoning: which areas contained the address, which rule chose, under which version.
Ask what a decision looks like when it comes back, not what the dashboard looks like.
Will it answer the same way everywhere?
The website, the call centre, the CRM and the field system will all ask the same question about the same address. If they each have their own copy of the rules, they will drift, and the first sign is a customer who was told two things.
Ask whether there is one ruleset with an API in front of it, or a definition per integration.
What to ignore
Map polish. You look at the editor for an hour a month. The decision runs thousands of times a day.
Radius drawing. Every tool has it, it takes ten minutes to build, and it is the least accurate way to describe a service area that exists.
Territory optimisation. Software proposing where boundaries should be needs inputs about demand, capacity and travel that almost nobody has clean, and its output is a suggestion somebody senior will overrule. Reasonable to want, wrong thing to buy on.
Seat counts. Pricing that charges per user pushes teams to share logins and keeps the people who understand the territories out of the tool.
The short version
The interesting questions are all about what happens when the answer is not a clean yes: refusals, capability, imprecision, history, disagreement. Every product demos well on the clean yes, because that is the one everybody built first.