docs: expand scope to local retail alongside services
- Strategy §1a: brick-and-mortar services + local retail in scope - Pure online e-com remains out (Shopify lane) - ICP, NORTH_STAR, README, product docs aligned - Add UC-03 general store (toothbrush / chicken strips case)
This commit is contained in:
@@ -6,6 +6,7 @@ Canonical use cases for product, engineering, and GTM. These are operating specs
|
||||
|----|------|-------|--------|
|
||||
| [UC-01](./uc-01-endpoint-auto-repair.md) | Endpoint activation — independent auto repair | Model 1 | Spec |
|
||||
| [UC-02](./uc-02-intermediate-tourism-board.md) | Intermediate activation — destination tourism board | Model 2 | Spec |
|
||||
| [UC-03](./uc-03-local-retail-general-store.md) | Endpoint activation — local retail / general store | Model 1 | Spec |
|
||||
|
||||
## How to write more of these
|
||||
|
||||
|
||||
@@ -0,0 +1,114 @@
|
||||
# UC-03 — Endpoint activation: local retail (general store)
|
||||
|
||||
**Status:** Spec
|
||||
**Business model:** Model 1 — Endpoint enablement
|
||||
**Primary surface:** Platform MCP + Self-Service Portal
|
||||
**Priority:** In vision and ICP from day one; implementation may follow first service pack, not exclude retail from strategy
|
||||
|
||||
---
|
||||
|
||||
## 1. Problem
|
||||
|
||||
A small local retailer (example: a general store in Athol, Idaho) is easy for a human neighbor to understand and hard for an AI assistant to represent honestly. The store’s website, if it exists, is thin. Reviews may mention chicken strips once in 2019. Nothing structured says they carry basic toiletries, what the house specialties are, or when to come by.
|
||||
|
||||
When a traveler or local asks ChatGPT whether that store has a toothbrush or is worth stopping for food, the assistant either guesses, recommends a chain, or stays vague. The store never sees the miss.
|
||||
|
||||
---
|
||||
|
||||
## 2. Desired outcome
|
||||
|
||||
The operator can publish structured local truth so an assistant can answer, with grounding in the store’s own data:
|
||||
|
||||
- Yes — they typically carry everyday items like toothbrushes
|
||||
- Yes — chicken strips (or another house specialty) are a known reason to stop
|
||||
- Hours, location, and visit/pickup expectations
|
||||
- Optional: limited “ask us” path if inventory is uncertain
|
||||
|
||||
This is **not** full real-time warehouse inventory for v1 unless the store already has a feed. Honest “we carry / house specialty / hours” beats fake precision.
|
||||
|
||||
---
|
||||
|
||||
## 3. Actors
|
||||
|
||||
| Actor | Role |
|
||||
|-------|------|
|
||||
| Owner / operator | Maintains what the store wants AI to say |
|
||||
| Consumer | Asks an assistant a place-based retail question |
|
||||
| AI assistant | External engine calling the MCP |
|
||||
| geolocal platform | Hosted MCP, portal, ingestion, telemetry |
|
||||
|
||||
---
|
||||
|
||||
## 4. Preconditions
|
||||
|
||||
- Physical store location
|
||||
- Ability to publish a discovery pointer (own site or simple landing page)
|
||||
- Operator can list categories, flagship items, and specialties in plain language
|
||||
- Optional later: POS/inventory integration for confirmed stock
|
||||
|
||||
---
|
||||
|
||||
## 5. Main success scenario
|
||||
|
||||
1. Operator signs up and chooses **local retail / general store** genre.
|
||||
2. Portal scrapes any existing site and reflects gaps.
|
||||
3. Operator enters or confirms: hours, categories carried, flagship items, house specialties, parking/visit notes.
|
||||
4. Simulation shows an assistant answering “toothbrush?” and “what’s good here?” using that structured truth.
|
||||
5. Pointer installed and preflight passes.
|
||||
6. Live endpoint serves tools such as business info, hours, assortment/specialty summary, visit path.
|
||||
7. Reports show what people (via agents) asked — including misses (“asked for propane; not listed”).
|
||||
|
||||
---
|
||||
|
||||
## 6. Alternate and exception paths
|
||||
|
||||
| ID | Case | Behavior |
|
||||
|----|------|----------|
|
||||
| A1 | No inventory system | Use “typically carry” categories and curated specialties; never claim live stock |
|
||||
| A2 | Hybrid sell + service | Combine retail primitives with service/booking tools (e.g. bike shop) |
|
||||
| E1 | Operator claims infinite stock for everything | Preflight/quality warnings; quality policy may quarantine misleading endpoints |
|
||||
| E2 | Pure online shop, no storefront | Out of ICP; route away |
|
||||
|
||||
---
|
||||
|
||||
## 7. Minimum MCP / genre contract (retail v1)
|
||||
|
||||
- Identity, location, hours
|
||||
- Categories typically carried
|
||||
- Flagship items / house specialties (named, short descriptions)
|
||||
- Visit guidance (walk-in, pickup window if any)
|
||||
- Optional phone/contact
|
||||
- Explicit inventory confidence level: curated list vs live feed
|
||||
|
||||
---
|
||||
|
||||
## 8. Success metrics
|
||||
|
||||
- Preflight pass with at least hours + one specialty or category set
|
||||
- Simulation answers a “do you have X?” and a “what’s special?” question without hallucination from empty fields
|
||||
- Weekly report shows retail-shaped intents (carry, hours, food specialty), not only appointment intents
|
||||
|
||||
---
|
||||
|
||||
## 9. Out of scope for UC-03 v1
|
||||
|
||||
- Full Shopify replacement or cart/checkout
|
||||
- Guaranteed real-time stock without a feed
|
||||
- Marketplace shopping across many stores in one consumer app
|
||||
|
||||
---
|
||||
|
||||
## 10. Dependencies
|
||||
|
||||
- Retail genre pack v1
|
||||
- Portal genre branch for retail
|
||||
- UC-01 platform mechanics (pointer, preflight, reports)
|
||||
- Strategy §1a scope (local retail in ICP)
|
||||
|
||||
---
|
||||
|
||||
## 11. Open questions
|
||||
|
||||
1. How much assortment is enough for go-live (categories only vs item list)?
|
||||
2. When do we integrate POS for true stock?
|
||||
3. How do we prevent spammy “we have everything” profiles?
|
||||
Reference in New Issue
Block a user