The short version
A shopper beside a product may want a specification or a comparison without searching for the right page. AskShelf connects the physical shelf label to a mobile product page and a voice conversation grounded in the retailer’s catalog.
Conceptual brand illustration
Product, owner and current status
Built and operated by Datahase Dev Private Limited, as stated in AskShelf’s privacy policy. Public product pages describe a retailer setup workflow and offer demos. The documented shopper journey runs in the browser without an app or account; no store installation, signup or voice session was tested for this study.
Public sources checked on
The everyday problem
The retailer holds product information in a catalog, while the shopper stands next to one physical item. The practical handoff is finding the relevant product context on the shopper’s own phone, then making a question possible without requiring a new application.
AskShelf’s walkthrough links catalog import, generated product pages, branded QR labels, browser voice interaction and retailer analytics. This study follows those steps as documented behavior. It does not turn demonstration screens, published accuracy claims or scan counts into evidence of sales outcomes.
Who does what
- The retailer maintains catalog context
- The retailer imports product data, reviews and refines product pages, and places QR labels near the corresponding items. Published branch catalogs and QR codes make location part of the operating context.
- The shopper chooses whether to speak
- The shopper scans to browse a mobile product page and can start a voice conversation. The feature and privacy pages say transcription is disclosed before speaking. Browsing does not require the shopper to install an app or create an account in the documented journey.
- The team reviews interaction records
- Authorized retailer team members use scans, transcripts and topic-level analysis. The feature page describes Owner, Admin and Member roles and branch-level permissions; this study does not independently validate enforcement or infer a larger enterprise permission model.
An illustrative workflow
Import and inspect the catalog
Add a fictional product by URL, CSV or manual entry. The walkthrough says the platform structures product details and produces a page; the retailer can edit it. Source data still needs checking for current specifications, pricing and branch context.
Connect the shelf to the page
Generate a branded product QR code, download it and place it beside the corresponding item. Scanning opens that item’s mobile page. Correct physical placement remains an operational responsibility; a readable code cannot tell whether staff placed it beside the right product.
Browse, then choose voice
The shopper reads the page and can tap the voice-agent entry point. Multilingual assistance is a published capability, not tested language coverage or a guarantee that every answer is correct. No platform-specific microphone behavior was exercised here.
Inspect what returns to the retailer
The dashboard is documented to expose scan analytics, conversation transcripts and analysis of questions or topics. A scan is an interaction event, not proof of intent or a purchase. Generated sentiment or intent classifications remain analysis rather than verified statements about a person.
Three product decisions
- Use the product page as an inspectable entry point
- The walkthrough separates scanning/browsing from starting a conversation. A shopper can see the catalog details before choosing voice. Our design reading is that the page provides shared product context, but this is not evidence that catalog import is always complete or answers are guaranteed to follow it.
- Keep branch context in the product workflow
- The feature page describes per-branch catalogs and QR codes, a shared product library and cross-branch analytics. These distinguish a product concept from its location-specific presentation. The architectural lesson is to preserve that context when updating pages and comparing activity; no stock-system integration or live inventory accuracy is inferred.
- Distinguish voice processing from retained records
- The feature and privacy pages say audio is streamed for processing rather than recorded/stored, while text transcriptions are retained. The privacy policy also describes session metadata and AI service-provider processing. “Audio not stored” therefore does not mean no processing, no retained conversation information or anonymous use.
What the product does
The official walkthrough documents URL/CSV/manual catalog ingestion, mobile product pages, downloadable branded QR codes and browser-based voice assistance. The feature page adds branch catalogs, team roles, activity logs and cross-branch analysis. These are first-party product descriptions rather than a verified deployment in a shop.
The shopper journey is described as app-free and signup-free. Retailer/team accounts are a different context. Optional customer-data forms described in the privacy policy are also a separate choice; they are not necessary evidence that every shopper provides identifying details.
Analytics needs an interpretation boundary
The published feature page describes scans by product, branch and time, conversation transcripts, sentiment analysis and purchase-intent signals. Those views can suggest questions for a retailer to inspect, such as whether product details need clarification. They do not establish that a question led to a sale or that a classification reflects a shopper’s actual intent.
Our engineering analysis is to keep event counts, transcript content and derived labels distinguishable, with appropriate team access. An evaluation would check a synthetic product’s branch mapping, wrong-label placement, stale catalog text and transcript disclosure before a staged conversation. None of those live product tests was performed here.
Data handling requires precise language
The March 2026 privacy policy identifies Datahase as the operator. It says voice audio is processed in real time and discarded, text transcripts are stored, and customers receive transcription notice before speaking. It also describes scan metadata and account/product data. This study reports that documented policy rather than asserting an independent storage or processor audit.
Retailer access to transcripts deserves a deliberate operational policy: who can review them, why they are needed and how requests are handled. Role-based access is a documented feature, not a blanket compliance guarantee. No latency, accuracy, conversion, daily-scan or total-session figure is used as an outcome.
Scope and boundaries
This is an owned-product documentation walkthrough. Public pages describe browser voice assistance and multilingual support, but no language coverage, voice accuracy, latency, retailer integration or live store installation was tested. Audio processing and transcript retention statements are attributed to the public policy, not independently audited. There is no measured conversion or sales claim and no fabricated customer dashboard; the illustration is conceptual brand artwork.
Inspect the sources
- Shelf-to-browser walkthrough
Catalog import, product pages, printed QR codes, browser voice and retailer analytics.
- Features and branch/team boundaries
Per-branch catalogs/QRs, roles, transcript-based analysis and pre-conversation notice.
- Operator and information handling
March 2026 policy: Datahase ownership, streamed audio, retained transcripts and scan/session metadata.