QR Closed-Loop & Sticker Packs

How estate sales track sales today (the gap)

Manual (most small/solo sales): handwritten/printed price stickers, color-coded tags, checkout = calculator + cash box; cards via Square "quick amount" (a dollar figure, not an item). Result: no item-level sold data — the day's total, not which items sold.
Square (~54% of EstateSales.NET sellers): dominant card processing, quick-add at checkout; rarely linked back to inventory.
Estate-sale POS (PROSALE, EstateSail): real item-level — print price+barcode+description labels, scan at checkout, image-verify, integrated payments. The minority, gated by cost/learning curve.
Auctions: lot numbers + barcodes + clerking → full item-level sold data (the gold standard the floor lacks).
QR price stickers already exist (Scanlily, branded 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:

Price tag on the floor.
Buyer portal — QR → the public item/sale page (not the seller's profile, though it links back there). Save/follow/wishlist feeds the demand graph; physical stickers become buyer acquisition. 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. (Reuses discount_phases, buyer_offers, alerts.)
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.
Consignor tag — binds the item to the right family/consignor → automatic commission split & settlement.

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) carry 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 spend to high-recovery goods — exactly the items worth item-level tracking, appraisal flags, buyer portals, and auction routing. Cheap/bulk stays manual.
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 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 pipeline).
Print-your-own — generate QR labels from the canonical record and print on a standard/label printer. 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 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 platform usage + buyer acquisition).
SKUs: standard label, weatherproof (outdoor/yard), hang-tag (antiques/fragile/no-stick). Pack sizes (e.g., 50 / 100 / 250).
Plan allotments: Estate includes N/mo, Pro more; overflow via packs (nudges upgrades).
Fulfillment: print-on-demand / dropship — no held stock.

Caveats → design resolutions

1 · Binding flow must be ~5s; offline-first

Two-scan bind with the camera staying open: scan blank sticker → tap/scan item → bound. Batch-bind mode down the filtered "flagged high-value" list. Codes are pre-generated (no server round-trip); events queue locally (IndexedDB) and sync on reconnect. Optimistic UI; pre-print = no printer step. Keep "print-from-record" as an alternative.

2 · Adhesive / durability

Spec removable, low-residue stock, small format. Default a hang-tag (string) variant for antiques / fragile / no-stick surfaces. Offer weatherproof synthetic for outdoor/yard sales. In-app guidance: hang-tag for anything finished or valuable.

3 · Checkout speed (beat a calculator; coexist with Square; optional)

Camera opens → scan QR → item + price auto-fill → one tap to confirm. Continuous multi-scan builds a cart, then one Square charge for the total — QR captures items, Square captures money. Manual entry stays; bulk/"fill-a-bag" stays manual. Optional per sale, never required. Phone default; optional Bluetooth ring-scanner. Target sub-2s/scan.

4 · Privacy

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

5 · Physical ops (shipping / SKUs / returns)

Print-on-demand / dropship — no held inventory. Small SKU set (standard / weatherproof / hang-tag × 2–3 sizes). Codes activate on the account at first scan, so lost packs carry no data risk. Returns: flat "report a problem → reship," not reverse logistics. Plan allotments smooth demand.

6 · Existing players (PROSALE / Scanlily)

Don't compete on the scan — integrate around it. Differentiation = the demand graph + Trove Go marketplace + disposition engine the scan feeds. Position as "the sticker that also lists your item, captures the sale, and routes the leftovers," not "another POS." Interop: import PROSALE/Square sold reports so those sellers 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.
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 the public QR.