How to evaluate retail site selection software

The fastest way to evaluate a site selection tool is to bring locations you already understand, a few that opened well and a few you passed on or now regret, and score them in the trial. Read what the tool says about each. If the scores line up with what you learned the hard way, and you can follow the reasoning behind them, the model has earned more of your time. If the numbers look right but you cannot tell why they came out that way, treat it as the first red flag. Everything below is a way to pressure-test that reasoning.

Start with explainability, because a score you cannot defend will not survive its first committee meeting. Ask to see a score split into its parts, so you can tell how much came from demographics, how much from nearby competition and traffic, and where the fit with your own format moved the number. A score you can take apart is one you can argue with and adjust. A single number with no breakdown puts you in the position of vouching for a black box, and committees notice.

How a tool defines a trade area changes every number downstream, so pin it down early. A one-mile or three-mile radius is easy to draw and easy to compare, but it assumes customers travel as the crow flies. Real catchments follow roads, and they bend around rivers, highways, and how long it takes to get somewhere at five in the afternoon. Drive-time and walk-time areas capture that, and they change which competitors actually compete and which households can realistically reach you. Ask whether the tool builds trade areas from the road network, whether it accounts for time of day, and whether you can switch methods to see how sensitive a site is to the choice.

Demographic and competition data ages, and stale inputs produce confident wrong answers. Find out what sources a tool uses, how often each one refreshes, and whether the vintage travels with the number. A population figure from the last census looks the same as one updated last quarter until you check the date, and by then it may already be in a board deck. Good software attaches a source and a date to every figure it shows, so when a reviewer asks where 45,000 came from, the answer is in the brief rather than in someone's memory.

A site can score well on its own and still be a mistake if most of its sales come from the store you already run two miles away. Any tool you evaluate should be able to look at a candidate in the context of your existing network and estimate how much of its demand is genuinely new versus pulled from your own units. For a single-location operator this matters less. For anyone adding stores to a market they already serve, it is one of the few analyses that flips a go decision to no-go, so test it with a candidate you suspect overlaps an existing store and see whether the tool catches it.

At some point the analysis has to leave the software and become a document someone can approve. Look closely at what the tool produces at the end. A committee-ready brief pulls the score, the trade area, the demographics, the competition, and the cannibalization read into one place, with sources attached, so the people deciding do not have to take your word for the inputs. A tool that gives you a dashboard but no exportable brief leaves you rebuilding the story in slides every time, which is where hours disappear and where the audit trail tends to break.

Some of the most capable platforms assume you have a GIS analyst who can build layers and maintain the data. If you have that team, those tools are powerful. If you do not, a self-serve product that produces a defensible score without specialist staff will actually get used, while a powerful one that requires a hire tends to sit idle. Be honest about who will run the software week to week, and take the trial as that person rather than as the most technical member of the group.

A few practical questions tend to get skipped until after the contract is signed. Find out whether your existing pipeline of candidate sites can go in, and the scores come back out, through a file or an API rather than by retyping. Ask what support looks like when a number seems wrong, whether someone will walk you through the methodology or point you at a help center. And look hard at the pricing model, because paying per seat, per analysis, or per location each shapes how freely the tool gets used. A per-analysis price can quietly discourage the exploration that makes the software worth buying in the first place. None of this shows up in a feature grid, and all of it decides whether the tool still earns its place a year from now.

A demo goes faster when you drive it with your own sites instead of the vendor sample. Hand over a couple of real candidates and ask for these in order:

• Take one of my candidate sites and show me its score broken into the parts that built it.
• Draw the trade area for this address by drive time, then by radius, and show me what changes.
• What is the source and the date behind the population and competition numbers on this site?
• How much of this site's projected demand is new, and how much is pulled from stores I already run?
• Export the brief you would hand a real estate committee, and walk me through what is on it.
• Who on my team has to run this each week, and what happens when a number looks wrong?