Retail Planogram: from shelf photo to decision
Deepanshu PalProduct sales did not provide a clear view of the actual shelf layout. Manual shelf capture and reporting separated the plan from the floor.
Context
This case study covers Retail Planogram, a shelf visibility system running at a supermarket chain in Southeast Asia. The client is unnamed and we do not publish its figures. The system runs on the retailer's own hardware, inside the building.
A planogram is a plan for where each product sits on a shelf. A retail chain's head office draws it, and the stores carry it out. The question this work starts from is a plain one: how would anyone know whether the shelf looks like the plan?
Problem
Sales systems report what sold. They do not report where it sat on the shelf, or whether the planned number of facings was there when it sold. Two separate gaps came out of the brief.
The plan and the floor drift apart
Manual shelf capture and reporting is slow, so the layout has changed again by the time the report reaches head office.
Sales have no shelf in them
A store-wide number does not say which row held a product, so it cannot say which shelf needs attention this morning.
The result is data without a decision. A report can say a product is selling less than expected. It cannot say whether the product was in the planned place, or on the shelf at all.
What was built
The system turns a phone photo of a shelf into a structured layout, checks it with a person, and ties it to sales. Five steps make up the workflow.
Photograph the shelf
A person takes a photo with a phone. No special capture rig is needed.
Match the products
Computer vision matches what is in the photo to the retailer's catalog.
Confirm the uncertain ones
A person checks the matches the system is not sure about.
Why The shelf layout is only useful if it is right. A human check on the uncertain cases keeps wrong matches out of the data.
Connect sales
The structured shelf is tied to sales down to the row and the product.
Decide what to fix
Staff work from a prioritized list of exceptions: empty facings, stalled products and shelves that are overdue for a new photo.
Each shelf can also be exported as a PDF report for store operations. It carries revenue, products, facings, a 30-day trend and revenue by weekday.
Why it runs on-prem
The deployment runs locally on the retailer's hardware. Shelf photos and point-of-sale data stay on site, and no vendor-controlled cloud is required. The retailer owns the model rather than paying per seat, store or call.
That is a trade, not a free win. Hardware, installation and operation still cost money, and they have to be scoped against the real store environment. We say so on the product page and repeat it here.
What is evidenced
The deployment gives the retailer shelf-, row- and slot-level visibility from a phone photo, with a human check on every uncertain match.
Runs in operation
A large Southeast Asian supermarket chain uses it today, on its own hardware.
Visibility down to the slot
Shelf, row and slot-level layout from a phone photo.
Before and after results
No verified before/after dataset is published.
Customer figures in the demo
Public demo dashboards use fictional stores and illustrative figures. They are not customer results.
Client identity
Withheld.
The scope is deliberate. Visibility is what the system provides. Whether a retailer then gains revenue from acting on it depends on what the store does with the exceptions, and we have not published that measurement.
What this says about machine customers
A shelf photo turned into structured data is a small version of a larger idea. An agent that shops for a person needs product, price and stock data that a machine can read. The shelf is where that data starts. A store that knows its own shelves as data is closer to being a store a machine customer can read.
The machine customer.
Commerce has a new reader. What changes when that reader can buy?
Read the manifesto