Retail Site Selection Software: Why Your Sales Forecast Cannot Be Reproduced Later

Why store development breaks on off-the-shelf site selection tools

The real estate committee meets Thursday. On the table is a 4,200 square foot end-cap in a grocery-anchored centre, ten year term, and the deal sheet forecasts $2.4M year one. The analyst built that number over two days from four analogue stores, a drive-time trade area, and a cannibalization haircut of 8 percent applied because the nearest store is 3.1 miles away and 8 percent felt right. Nobody in the room can reconstruct the 8 percent. Eighteen months later the store does $1.7M, the neighbouring store is down 6 percent, and the post-mortem cannot establish whether the forecast was wrong, the cannibalization was worse than assumed, or the centre lost its anchor. The spreadsheet that produced the forecast has been overwritten nine times since.

The tool stack is usually Placer.ai for foot traffic and trade area visitation, Esri Business Analyst for demographics and drive times, sometimes a Buxton or Kalibrate model engagement, a CoStar or brokerage feed for available space, and Excel holding the actual decision. Each of those does its job. Placer.ai genuinely tells you where visitors come from and where else they go. Esri gives you clean demographics and a defensible isochrone. Buxton will build you a model. What none of them gives you is a forecast that is yours, reproducible, versioned, and connected to the specific estate you already trade.

Problem 1: the forecast has to be trained on your stores, not on a generic retail model

Your sales come from your format, your assortment, your price position, your hours, your co-tenancy, and your brand awareness in a given market. A model trained on retail in general knows none of that. A model trained on your own trading estate knows all of it implicitly, which is why analogue methods have survived every wave of fashionable analytics.

The vendors are honest about this in different ways. Buxton and Kalibrate build a bespoke model precisely because generic ones do not work, and Kalibrate in particular is strong in fuel and convenience where the gravity mechanics are well understood. The problem is not the modelling, it is the ownership and cadence. The model is delivered as an engagement. You cannot open it, you cannot retrain it monthly as new stores mature, and the assumptions live with the vendor's analysts rather than with your team.

What a custom build does: hold your own store-level history, weekly sales by store with trading calendar, alongside the site attributes that mattered, and fit the model on that. The specification matters more than the algorithm. Analogue selection should be explicit and inspectable, meaning the system names the comparable stores and their weights on screen. Model form should stay simple enough to defend in a room, usually a regression on a set of drivers you can articulate plus a gravity component for competition and own-store overlap, because a committee will not approve a decade of rent on a number it cannot interrogate. And every forecast should be stored as an immutable version with the input snapshot attached, so the post-audit in year two compares against exactly what was approved rather than against a workbook that has moved on.

Problem 2: cannibalization is a transfer between named stores, not a haircut

The moment a chain has density, the site question stops being how much will this store do and becomes how much will the chain gain. Those diverge sharply in mature markets, and the gap is where over-building happens.

A percentage haircut cannot express this. It hides which store loses, how much, and whether that store is already marginal on its own lease economics. It also hides the reverse case, where a new store relieves a capacity-constrained location and lifts total market sales rather than splitting them, which is a real effect in food service and pharmacy and one that pure overlap logic gets backwards.

What a custom build does: model transfer explicitly at the customer origin level. Trade areas are built from actual visitation origins where you have mobile location data, or from loyalty and transaction postcodes where you have them, which most retailers do and underuse badly. Then the new site competes for each origin block against every existing store using distance, drive time, and relative attractiveness, and the output is a named transfer table: this store loses $180,000, that one loses $60,000, net new to the chain is $1.9M against a gross forecast of $2.4M. The committee now approves a net number. This single change alters which deals get done, and in our experience it kills roughly one deal in six that would otherwise have been approved on gross sales.

Problem 3: the committee paper is the product, and it is assembled by hand

Whatever the analytics, the deliverable is a document that a group of executives approves. It contains the forecast, the assumptions, the competitive picture, the cannibalization impact, the capex, the lease terms, the store P&L projection, the return metrics, and a map. Today someone spends a day and a half building it, pasting screenshots from four tools, and the version approved is a PDF whose underlying numbers cannot be regenerated.

What a custom build does: generate the committee pack from the system with a locked input snapshot, a version number, and a named approver. Every figure in it traces to the data and the model version that produced it. Changes after circulation are visible as changes. Then, and this is the part that compounds, the same record becomes the back-test: when the store has 12 months of trading, the system compares actual against forecast automatically, attributes the variance to the components it can, and feeds that error back into the next model refit. Chains that do this stop arguing about whether the model works and start knowing its error band by format and market type, which is what lets you set an approval threshold honestly.

Problem 4: the pipeline is a spreadsheet with hard dates and real money

Between first look and opening day sit letters of intent, lease negotiation, landlord work letters, permitting, fit-out, and a construction calendar, each with dates that slip and each with a cost of slipping. Meanwhile broker submissions arrive constantly and most are noise.

What a custom build does: put the pipeline on the same map and the same model as everything else. A deal in negotiation is a hypothetical store that participates in the transfer calculation, so a second site in the same trade area shows its impact on the first before either is signed. Broker submissions get an automatic first-pass screen against your minimum thresholds so the team spends its judgement on the twenty candidates worth judging rather than the two hundred that are not. Approval workflow carries the real gates: concept approval, committee approval, lease execution, capex release, each with the pack version attached.

Problem 5: the data is expensive and you are probably paying twice

Mobile location data, demographic panels, competitor point-of-interest files, traffic counts, brokerage listings. Most chains buy several of these and use a fraction of each, often because the tool that consumes one cannot consume the others.

What a custom build does: treat these as inputs rather than as products. Placer.ai and similar providers expose their data programmatically, which means visitation and trade area inputs can flow into your model rather than being read off someone else's dashboard. Your own loyalty and transaction data joins on the same geography and is usually the highest-value input you have, because it is behavioural, specific to your customers, and free. The build should be explicit about which vendor feeds are load-bearing, because a model that cannot be reproduced without a subscription you might cancel is a liability worth knowing about in advance.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A first release covering the trade area engine, the analogue forecast trained on your estate, explicit cannibalization and transfer modelling, and a reproducible committee pack runs $80,000 to $180,000 and ships in 12 to 18 weeks. A full platform adding pipeline and approval workflow, market planning and white space analysis, post-opening back-testing with automatic model refit, and integration with lease administration, POS and construction scheduling runs $200,000 to $500,000 phased over 6 to 12 months.

What drives price up in this category: the state of your own sales history, which is the single biggest variable, because a chain with clean weekly store-level sales and a trading calendar is a very different project from one where sales sit in three systems after two acquisitions. Multiple formats, since a 1,200 square foot kiosk and a 20,000 square foot flagship need different models, not one model with a size variable. International markets, where the demographic data model changes completely per country. Franchise structures, where territory encroachment rules are contractual and must be enforced rather than merely analysed. And drive-time routing at scale, which is a genuine engineering cost if you are running millions of origin-to-store calculations per scenario.

Build versus buy, and when buying is the right answer

Buy if you open fewer than about 8 stores a year. The analyst time saved will not cover a build, and Placer.ai plus Esri Business Analyst plus a disciplined spreadsheet is genuinely adequate. Buy if you have fewer than roughly 40 trading stores, because there is not enough signal to train a model on and any forecast is judgement wearing a lab coat. And buy a Buxton or Kalibrate engagement if what you need is a credible model quickly for a board that has lost confidence, since a bespoke vendor model delivered in a quarter is a reasonable bridge.

Build when several of these are true. You open 15 or more stores a year and the analyst team is the bottleneck. You are dense enough in core markets that cannibalization is a live argument in every committee. You have been burned by a forecast you cannot now explain. You want the model to improve as stores mature rather than being refreshed by a vendor engagement every few years. You run franchise or dealer territories where encroachment is contractual. Or you have loyalty and transaction data covering a meaningful share of sales, which is the strongest single reason to build, because that data is the one input your competitors cannot buy.

Our position: the tipping point is density, not store count. Once new stores routinely take sales from existing ones, a tool that forecasts a site in isolation is answering the wrong question, and no amount of dashboard quality fixes that.

How to choose a developer for site selection software

Ask them how they would model cannibalization before you talk about anything else. The answer you want is competition for demand at the origin level producing a named transfer table by store. If the answer is a distance-based percentage adjustment, they will build you a prettier version of the spreadsheet you already have.

Ask how forecasts are versioned and how a committee pack is reproduced two years later. If versioning and input snapshots are not in the first answer, governance is not something they have thought about, and governance is most of the value here.

Ask who owns the code and the model, in writing, before kickoff. You should own the repository, the infrastructure accounts, the trained model, and the right to hire anyone else to continue. At Digital Heroes that is the default from the first commit. A forecasting model built on your own trading history is a competitive asset, and it should never sit in someone else's account.