Insights / Retail operations and store technology
What a QR store finder needs before it can work
A shopper scans a code, asks for a product and is told where it is. The interface takes little effort to build. Whether the answer is right depends on data most retailers hold in several places, so that is where a pilot should start.
Shelf locations come first
The first question is whether each store can say where a SKU sits, down to the aisle and bay. Planograms often describe where a product should be, while the shopper needs where it is today. If no usable SKU-to-bay source exists, mapping one store is the first piece of work, and it is worth costing before anything else.
Variants decide whether the answer helps
People rarely want a tent. They want a size, a colour or a fitting. The finder needs variants linked to a parent product, and the names shoppers actually use mapped to catalogue terms. When a question is ambiguous, asking which variant is better than picking one.
Stock needs a stated freshness
A stock count from last night can send someone to an empty bay. Agree how old a count may be before the finder stops quoting it, show its age, and fall back to saying the product is usually stocked here, or to the service desk. Sample numbers in a demo should always be labelled as sample numbers.
Unknown has to be an allowed answer
A confident wrong aisle costs more trust than a plain “I can't find that, ask at the service desk”. Test the finder on products that are out of range, discontinued or missing a location, and treat an invented answer as a failure.
Questions to settle before a one-store pilot
- Which system holds the SKU-to-aisle and bay mapping, and who keeps it current?
- How are variants and parent products linked in the catalogue?
- How often can stock be read for one store, and by what method?
- Does the phone signal or store Wi-Fi hold up in the back aisles?
- What will you measure, and against which baseline? For example, questions answered without staff help, checked by spot audit against the shelf.