Most in-store analytics projects don't fail. They never start. Someone sees the value, sketches a business case, prices a store-wide rollout, and watches finance close the door on a six-figure programme that hasn't proved anything yet. The idea is sound; the scope is wrong.

The way through is to invert the order. Don't ask for budget to transform the store. Ask for a few weeks to prove a single point in a single department, using cameras you already own. A well-run in-store analytics proof of concept costs little, carries almost no risk, and produces the one thing a stalled business case lacks: evidence. This is how to scope one that gets funded and tells you something worth knowing.

A POC proves a commercial question, not a technology

The first mistake is treating the pilot as a tech demo. Whether computer vision can count people and measure dwell time is not in doubt; it can. What you're actually testing is whether the resulting insight changes a decision the business already cares about.

So a good POC starts from a question, not a camera. Something specific and commercial: Why does this department get strong footfall but weak conversion? Which displays in this zone get walked past? Are we staffing this area to actual traffic or to a rota set last quarter? If you can name the decision the data will inform, you can prove value. If you can't, you'll produce dashboards nobody uses.

Pick a question where the answer is likely to be both surprising and actionable. A department your team argues about is ideal, because the pilot settles the argument with data instead of opinion.

Scope it small on purpose

The discipline that makes a POC fundable is restraint. One department. One or two existing camera feeds with decent coverage of that space. A run of a few weeks, long enough to capture normal trading patterns and at least one weekend.

That's it. You are not instrumenting the building, integrating every system, or committing to a platform. You're answering one question cheaply. Keeping scope this tight does three things: it drops the cost to something a manager can approve without escalation, it shortens time-to-evidence to weeks rather than quarters, and it removes the risk that sinks larger projects, because if it doesn't work, you've spent very little finding out.

Define five things before you start

A pilot lives or dies on its setup. Before any camera is pointed at anything, pin down five things:

1. The zone. One department with clear camera sightlines and enough traffic to produce meaningful patterns.

2. The question. The single commercial decision the data will inform.

3. The feeds. Which existing cameras you'll use, and whether their angle and image quality are good enough. A short technical check here saves weeks later.

4. The success metric. What result would make this worth scaling - for example, identifying a specific dead zone, or showing a measurable gap between footfall and conversion.

5. The owner. Who receives the insight and is positioned to act on it. A pilot with no one to act on the findings is a science project.

Write these down before kick-off. A pilot that drifts because nobody agreed what it was for is the most common quiet failure.

Architecture without rebuilding anything

You don't need a new network for a POC. The practical pattern is hybrid: anything time-sensitive runs at the edge, near the camera, while trend reporting, heat maps and historical analysis run in the cloud where they're easier to work with. For a pilot focused on dwell time and zone behaviour rather than real-time alerts, most of the processing can sit in the cloud, keeping the on-site footprint minimal.

The point is that you're adding a lightweight processing layer to feeds that already exist, not laying cable or buying sensors. That's exactly why the cost stays low and the install stays simple.

What "good" looks like

Two standards separate a credible pilot from a misleading one.

First, accuracy under real conditions. Insist on detection accuracy in the region of 95% under your store's actual lighting and layout before anyone discusses scaling. A model that performs in a vendor demo but stumbles in your conditions will produce confident, wrong data, which is worse than no data.

Second, the output has to land where people already look. The fastest way to waste a good pilot is to bury its findings in a dashboard nobody opens. Insight only creates value when it turns into an action: move the display, change the rota, reposition the range, open the till. If the POC ends with a clear "do this differently and watch what happens," it has done its job.

Proving ROI

Return on a pilot comes from connecting behaviour to outcomes. On its own, footfall and dwell data describe the store. Linked to point-of-sale data, they explain it, showing whether traffic is converting and where it isn't.

A simple, defensible way to demonstrate ROI: use the pilot to identify one fixable problem, make the change, and measure the before-and-after. Suppose the data shows a high-margin display in a low-traffic corner that almost no one reaches. You move it onto the main route the cameras reveal, and you track sales of those lines for the following weeks. If they lift, you have an attributable result tied to a specific, repeatable insight, and a number to put in front of finance.

That's the move that turns a pilot into a programme. Not a promise of insight, but a worked example of insight changing a decision and the decision changing the till.

One caveat worth building into the design: isolate the variable. Retail sales move for many reasons - weather, promotions, seasonality, a competitor's sale down the road. The cleaner your before-and-after comparison, the harder the result is to argue with, so where you can, hold other factors steady and avoid running the test across a major promotional period. You don't need laboratory conditions, but a result that survives obvious objections is the one that unlocks the next round of budget. A modest, defensible uplift beats an impressive number nobody believes.

From pilot to rollout

Once a POC has paid back, the build-versus-buy question becomes answerable, because now you know what the insight is worth. A single proven department is a different proposition from a standardised chain, and you can size the rollout against real evidence rather than a vendor's projection.

This is also the right moment to weigh platforms properly. Mature products such as RetailNext, Density or Placer.ai offer speed and support in exchange for licence costs; open-source computer-vision pipelines offer low software cost in exchange for engineering ownership. You'll make that call far better after a pilot than before one, because you'll know your accuracy requirements, your coverage gaps, and the scale you're actually solving for.

A fundable first step

The reason this approach works is that it asks for very little and shows its working quickly, which is precisely what gets approved in a constrained year. One department, the cameras already pointing at it, a few weeks, and a question worth answering. You prove the value before you ask for the budget, rather than the other way round.

The store has been generating this data all along. A small, well-scoped pilot is simply the cheapest way to start reading it.

Ready to scope one? Get in touch for a 30-minute conversation about your camera estate.