AI photo review for Quant store photos

Overview

An implementation photo in Quant is proof that a shelf was built, and it is also an unread picture of the whole store around that shelf. Quant collects those photos properly: they arrive attached to the planogram or the fixture they belong to, stamped with the store, the uploader and the day, and its Image Recognition scores how faithfully the products match the plan. What no schedule allows for is a person opening all of them and asking a second question, which is what condition that store was in. RapidEye reads the same photos your stores are already uploading and returns one finding per issue, with the store, the fixture, the photo and a suggested next step.

How it works with Quant

Quant gives a photo three things most systems never give it: a store, a fixture and a planogram it belongs to. That context is what makes an automated read useful, because a finding can say where in the store the problem is rather than just that a problem exists. Here is what RapidEye does with each kind of photo Quant holds.

• Implementation photos on planograms. Uploaded by the store when it confirms a planogram, and required if you tick Implementation Photo Required at publishing. RapidEye reads the frame around the products: a shelf that has lost a strip, a gondola end with the header hanging, water on the floor under a chiller, a light out over the bay. The finding carries the store, the planogram the photo was uploaded against, and the photo itself.
• Photos on fixtures. Quant lets a photo be assigned to a specific fixture with a note, and keeps a Photos tab on that fixture. Read in sequence, those become a history of one piece of equipment, so a bent shelf or a cracked door frame shows up as something that appeared between two dates rather than as an opinion.
• Photos on the store as a whole. The general ones: an aisle at opening, a back room, a queue area. These are where cleanliness, obstruction and safety issues live, and they are the photos least likely to be opened by anyone at head office.
• Photos attached to form answers. A Quant form question can carry a note and an uploaded image, which is how a district manager visit gets documented. RapidEye reads those photos too, so the score the visit produced and what the camera actually saw can be compared.

A finding names the store, where in the store, the kind of issue, how serious it looks, the photo it came from and a suggested next step, and it lands in the RapidEye dashboard, with a Slack channel or an inbox for the ops team if you want one. Nothing is written back: your planograms, tasks, states and photo library stay exactly as Quant left them, and you decide whether a finding becomes a task there. If your stores also shoot video walkthroughs, or you run a condition standard of your own that is not any of the above, that is a setup conversation, not a limit; RapidEye reads whatever documentation a team already produces and reports against whatever standard you care about.

How to connect Quant to RapidEye

1. A Quant account and the stores in scope. Photos in Quant are organised by store, under Recent Photos and Store Photos, so the scope of a connection is a list of stores rather than a list of planograms.
2. The photos you already have. Quant carries them: implementation photos uploaded at planogram confirmation, plus photos attached to fixtures and to the store. RapidEye reads those. If part of your condition checking happens away from Quant, a RapidEye capture link supplies those frames from any phone, no app to install, a fixed set of angles.
3. An invite. Add RapidEye as a user in Quant and send it login details. The modal has the exact path and the address to use.

What a Quant implementation photo actually holds

Checked against Quant's help centre, September 2026.

Quant is space planning, category management and store operations in one platform, built by Quant Retail and used by chains that publish planograms centrally and have store staff build them. The part that matters here is the loop between head office and the shelf. According to Quant's help centre documentation (quantretail.com), a planogram is published to a store, the store opens it in Quant Web on a phone, tablet or desktop with nothing to install, and confirms implementation once the goods are out. If the planogram was published with Implementation Photo Required, Quant Web will not accept that confirmation without a photo, and the photo is then shown beside the planogram so the two can be compared.

Everything that arrives collects in the Photos section, split into Recent Photos, which is every store newest first, and Store Photos, which is one store's library. Each photo shows the store it belongs to, who uploaded it and the day. From the photo itself Quant offers Download, Show in Floor Plan, Show in Planogram, Create Task, Rotate and Delete, so the photo is one click from the fixture on the floor plan and one click from becoming a task with the context already filled in.

One photo, two questions

Quant's Image Recognition answers the first of them well. Quant's documentation describes it comparing an implementation photo with the planogram it belongs to, marking correctly placed products with green boxes and products that should not be on the shelf with red ones, and reporting an implementation quality percentage behind a colour indicator, with annotations, bounding boxes and a crop adjustment for photos shot at an angle. Access to the detection results is itself a web right. It is a product-level read, and it is the right read for planogram compliance. The second question, what condition this store is in, is a different read of the same pixels, and it is nobody's job.

Where a finding would land in your task setup

Quant's task management is unusual in that a task carries a retail context rather than a typed-out description. Its documentation lists the contexts a task can be reported against, and one of them is the implementation photo itself.

The two highlighted contexts are the ones a condition finding maps onto most naturally.

Task types are yours to define per context, and Quant's own examples for the Fixture context are Broken fixture, Missing fixture and Wrong dimensions, which is exactly the vocabulary a condition finding needs. States run from Draft and Opened through In Progress, Waiting and Resolved to Closed, with a Validation state type available if a fix has to be signed off. Photos can be annotated in the built-in editor, notifications go out on status changes, comments and missed deadlines, and a task can be assigned to a group of stores in bulk with the store's own manager filled in automatically. None of that changes when RapidEye is connected. What changes is that the flagged photo reaches the right person because something read it, rather than because somebody happened to scroll past it.

Does Quant show you which photos have a problem you have not defined yet?

Not by design, and it is not meant to. Quant's photo tooling is anchored to the planogram: the recognition compares products to positions, the quality percentage measures the plan, and the sorting is chronological or by that score. A cracked shelf edge in the corner of the frame is not a planogram deviation, so it does not score, and a photo can be scored highly with a mess in it. That is a description of what the tool is for, not a shortcoming; the deficit is in the hours. Across a few hundred stores confirming planograms every week, the photo library grows faster than anyone reviews it, and RapidEye's contribution is simply that all of it gets read.

Quant integration FAQ