# QR Closed-Loop & Sticker-Pack Monetization

> Research + strategy, 2026-06-17. How estate sales track sales today, why a QR
> sticker closes the pipeline's inbound loop, and how sellable QR sticker packs
> become a self-targeting revenue line. Includes design resolutions for the known
> caveats.
>
> Closed-loop diagram: [qr-closed-loop.svg](qr-closed-loop.svg) ([PNG](qr-closed-loop.png)).
>
> Builds on [post-sale-inventory-disposition](post-sale-inventory-disposition.html)
> and the pipeline [pressure-test](pipeline-pressure-test.html). Differentiation
> note: the scan is the bridge; the demand graph + marketplace + disposition are
> the moat.

## How estate sales track sales today (the gap)

A spectrum from manual to software:
- **Manual (most small/solo sales):** handwritten/printed price stickers, color-coded
  tags (price tiers or per-family), checkout = calculator + cash box; cards via
  **Square "quick amount"** (a dollar figure, not an item). Result: **no
  item-level sold data** — you know the day's total, not which items sold.
- **Square (~54% of EstateSales.NET sellers):** dominant card processing,
  quick-add at checkout; still rarely linked back to specific inventory.
- **Estate-sale POS (PROSALE, EstateSail):** real item-level — print
  price+barcode+description labels, scan at checkout, image-verify, integrated
  payments, analytics. The minority, gated by cost/learning curve.
- **Auctions:** lot numbers + barcodes + clerking → full item-level sold data
  (the gold standard the in-person floor lacks).
- **QR price stickers already exist** (Scanlily, branded QR tags) — validated but
  fragmented, not tied to a demand/marketplace pipeline.

The recurring gap: the in-person floor produces **no itemized sold/unsold truth**,
so TroveSnap reconstructs it later from messy CSVs. QR-at-checkout fixes that.

## The closed loop (one sticker, four jobs)

A QR sticker bound to TroveSnap's existing item record is simultaneously:
1. **Price tag** on the floor.
2. **Buyer portal** — QR → the public **item/sale page** (not the seller's
   profile, though it links back there). Buyers can save/follow/wishlist → feeds
   the demand graph; physical stickers become buyer acquisition. Crucially, a
   shopper can **"notify me" to watch the item** and get pinged when it hits the
   next **discount phase** (day-2/day-3 markdowns), or **make an offer** on the
   spot — so lingering, marked-down inventory keeps moving instead of dying on
   the table. (Reuses existing `discount_phases`, `buyer_offers`, and alerts.)
3. **Item-level sold capture** — scan at checkout writes the sold event + final
   price to `inventory_status_events` in real time, **eliminating CSV
   reconciliation** and completing the pipeline's inbound half.
4. **Consignor tag** — binds the item to the right family/consignor → automatic
   commission split & per-consignor settlement (the agency use case).

The sold/unsold truth then **loops back** into pricing, demand, and disposition
(auction export, wishlist recovery), and makes the live dashboard genuinely live.

## Sticker-pack monetization (sellable consumable)

- **Razor & blades:** the **stickers are the consumable, the platform is the
  value.** Pre-printed packs (no printer required) carrying **blank unique
  codes** that bind to an item on first scan.
- **Selective use is a feature:** sellers sticker only their **most auctionable
  items**, self-targeting the spend to high-recovery goods — exactly the items
  worth item-level tracking, appraisal flags, buyer portals, and auction routing.
  Cheap/bulk stays manual ("fill-a-bag").
- **The app drives the sale:** the review queue already flags
  `appraisal_recommended` high-value items — it can prompt *"sticker these 18
  flagged items,"* turning a flag into a physical action and a pack sale.
- **Every sticker is distribution:** branded QR labels at every sale are "scan →
  Trove Go" billboards in front of the exact buyers to acquire.

### Two ways to get labels (both sync)

- **Pre-printed sticker packs** — the sellable consumable; no printer required.
  Their real job beyond convenience: **pre-tag the items a seller already knows
  can be auctioned later**, giving **item-level inventory tracking from day one**
  for future auction candidates (feeds straight into the
  [auction-outbound](auction-outbound-integration-spec.html) pipeline).
- **Print-your-own** — generate QR labels from the canonical record and print on a
  standard/label printer for shops that prefer it. **Either way the codes
  synchronize**: self-printed codes register to the account exactly like pack
  codes, so binding, sold-capture, and analytics work identically. Pre-printed =
  blank codes that bind on first scan; print-your-own = codes minted from the
  record at print time.

### Scan-interest metrics (gauging auction demand)

Every buyer/hunter scan of a QR at the sale is a **lightweight interest signal**.
Aggregated per item, **scan counts become an auction-demand gauge**: the items
hunters keep scanning are the ones with real pull — exactly the signal a seller
wants when deciding what to route to auction vs. clearance vs. donation. Scans
feed the **demand graph** alongside wishlist matches and surface as a per-item
interest metric on the live dashboard and in the What's Next recommendations. (No
login required to scan; counts are anonymous interest, not buyer identity.)

### Pricing notes (proposed SKU for `pricing-and-tokens.md`)

- **QR sticker packs** — the *only* physical SKU. Gateway-priced (margin
  secondary; value is the platform usage + buyer acquisition it drives).
- SKUs: **standard label**, **weatherproof** (outdoor/yard), **hang-tag** (string
  tag for antiques/fragile/no-stick). Pack sizes (e.g., 50 / 100 / 250).
- **Plan allotments:** Estate tier includes N stickers/mo, Pro includes more;
  overflow via packs (nudges upgrades).
- **Fulfillment: print-on-demand / dropship** — TroveSnap holds no stock.

## Caveats → design resolutions

**1. Binding flow must be ~5s; offline-first.**
Two-scan bind with the camera staying open: scan the blank sticker code → tap/scan
the item card → bound. **Batch-bind mode**: work down the filtered "flagged
high-value" list, scanning sticker after sticker. Codes are **pre-generated**, so
binding needs no server round-trip; events queue locally (IndexedDB) and **sync
when connectivity returns** (sale sites have bad wifi). Optimistic UI. Pre-print =
no printer step. Keep "print-from-record" as an alternative for label-printer
shops.

**2. Adhesive / durability.**
Spec **removable, low-residue** label stock; small format. Default a **hang-tag
(string) variant for antiques / fragile / no-stick surfaces** so nothing adheres
to delicate finishes. Offer a **weatherproof synthetic** stock for outdoor/yard
sales. Guidance in-app: hang-tag for anything finished or valuable.

**3. Checkout speed (must beat a calculator; coexist with Square; optional).**
Checkout PWA opens the camera, scan QR → item + price auto-fill → one tap to
confirm. **Continuous multi-scan**: build a cart of scanned items, then one Square
charge for the total — **QR captures the items, Square captures the money.**
Manual amount entry stays available; bulk/"fill-a-bag" stays manual. **Optional
per sale, never required.** Phone default; optional Bluetooth ring-scanner for
high-volume registers. Target sub-2s/scan.

**4. Privacy.**
The QR resolves to the **public buyer listing only**; the code is an **opaque id**,
never the price or internal data. **Internal pricing guidance, cost, and consignor
margins stay behind auth** and are shown only in the staff/checkout view — never
in the public payload.

**5. Physical ops (shipping / SKUs / returns).**
**Print-on-demand / dropship** partner — no held inventory. Small SKU set (standard
/ weatherproof / hang-tag × 2–3 sizes). Codes **activate on the account at first
scan**, so lost/undelivered packs carry no data risk. Returns: treat as low-value
consumables — **flat "report a problem → reship"** rather than reverse logistics.
Plan allotments smooth demand.

**6. Existing players (PROSALE / Scanlily do QR/barcode POS).**
**Don't compete on the scan/POS feature — integrate around it.** Differentiation =
the **demand graph + Trove Go marketplace + disposition engine** the scan feeds.
Position as "the sticker that also lists your item to buyers, captures the sale,
and routes the leftovers," not "another POS." **Interop:** import sold reports
from PROSALE/Square so sellers on those tools still feed TroveSnap. The scan is the
bridge; the network is the moat.

## Pipeline integration & phasing

- **Now (deterministic, no Auth):** generate/print QR labels from existing records;
  public QR → buyer listing page.
- **Phase 2 (Auth + connectors):** checkout-scan PWA (offline-first) writing
  item-level sold events; consignor binding + settlement; live-dashboard streaming.
- **Bridge, not rebuild:** payment stays on Square; TroveSnap reconciles item ↔
  money. Consistent with the no-payments core stance.

## Sources

- EstateSales.NET (POS, ~54% Square), PROSALE, EstateSail — POS & item-level tracking.
- OpenLabelMaker, Amazon/Etsy tag listings — color/numbered/barcoded estate tags.
- Sortly (QR vs barcode), Scanlily — QR inventory for estate sales.

*Pricing/SKU sketch is a proposal for `docs/product/pricing-and-tokens.md`, kept
here to avoid editing the canonical doc. Surface no internal pricing on public QR.*