docs: restore full strategy depth; add UC-01 and UC-02
- Expand CANONICAL_STRATEGY with retrieval substrates, commerce chairs, multi-path discovery, ingestion, quality/decommission, trust bar - Rebalance platform vs SSP (portal is activation, not the company) - Add principal-PM use cases for endpoint auto repair and tourism board - Update product docs and README entry points
This commit is contained in:
VPS admin
@@ -0,0 +1,155 @@
|
||||
# UC-01 — Endpoint activation: independent auto repair shop
|
||||
|
||||
**Status:** Spec
|
||||
**Business model:** Model 1 — Endpoint enablement
|
||||
**Primary surface:** Platform MCP + Self-Service Portal (activation)
|
||||
**Priority:** P0 (shapes Priority 0 engineering)
|
||||
|
||||
---
|
||||
|
||||
## 1. Problem
|
||||
|
||||
An independent auto repair shop (example: a transmission-focused garage in a suburban market) is increasingly invisible when consumers ask AI assistants for help. The shop may have a basic website and a Google listing, but those surfaces rarely expose specialization, services, availability, or a clean booking path in a form assistants can use. When an engine shortlists and then inspects the site, it finds ambiguity. The shop loses the recommendation moment without ever knowing it happened.
|
||||
|
||||
---
|
||||
|
||||
## 2. Desired outcome
|
||||
|
||||
Within one session, the owner (or a trusted family member / local web person) can:
|
||||
|
||||
1. Create a geolocal presence for the shop
|
||||
2. See how an assistant would currently understand them
|
||||
3. Attach a simple discovery pointer on their site
|
||||
4. Verify the live MCP answers correctly for their services
|
||||
5. Understand what to fix next
|
||||
6. Start receiving basic interaction reporting
|
||||
|
||||
The shop becomes machine-legible and bookable through assistants **without** buying a customer-facing chatbot product.
|
||||
|
||||
---
|
||||
|
||||
## 3. Actors
|
||||
|
||||
| Actor | Role |
|
||||
|-------|------|
|
||||
| **Owner or operator** | Decision maker; may not be technical |
|
||||
| **Delegate** (optional) | Daughter, office manager, or local web partner implementing the pointer |
|
||||
| **AI assistant** (external) | ChatGPT, Gemini, Claude, Copilot-class systems requesting local help |
|
||||
| **End consumer** | Person asking the assistant for a repair |
|
||||
| **geolocal platform** | Hosted MCP, ingestion, portal, telemetry |
|
||||
|
||||
---
|
||||
|
||||
## 4. Preconditions
|
||||
|
||||
- Shop has some public web presence (even a thin site) or can publish a single page that can hold a pointer
|
||||
- Shop can accept appointments (phone calendar is a weak start; Cal.com or equivalent is preferred for fulfillment path)
|
||||
- Operator can complete a web signup flow
|
||||
- For full fulfillment demo: a booking link or integrated booking endpoint exists or can be created during onboarding
|
||||
|
||||
---
|
||||
|
||||
## 5. Main success scenario
|
||||
|
||||
1. **Arrive** — Operator opens geolocal.io and starts “add my business.”
|
||||
2. **Genre selection** — They identify as automotive / auto repair. The experience switches to auto-repair language and examples (not generic SMB fluff).
|
||||
3. **Identity capture** — Name, location, website URL, phone, hours if known.
|
||||
4. **Initial scrape / reflection** — Platform fetches public site content and shows what it can already see: services mentioned, specialties, gaps, confusion.
|
||||
5. **Value simulation** — Portal shows a phone-and-chat style simulation: an assistant recommends this shop for a Korean-transmission style job, lists services it believes are offered, and proposes an appointment path (e.g. Thursday 3:00). Operator gets the aha: pre-qualified, in-scope demand.
|
||||
6. **Pointer install** — Portal gives a tiny attachment (well-known file, link tag, or equivalent multi-path option) pointing to the hosted MCP for this business. Operator or delegate installs it.
|
||||
7. **Preflight** — Portal runs a live test against the MCP (not a scripted mock). If services, specialty, hours, or booking path are wrong or missing, failures are explicit.
|
||||
8. **Correct** — Operator edits portal fields and/or site content; preflight re-runs until critical checks pass.
|
||||
9. **Upstream guidance** — Portal explains that MCP only helps after engines can find the site; offers a short findability checklist and optional partner referral.
|
||||
10. **Go live** — Endpoint is marked live. External agents that discover the pointer can call structured tools.
|
||||
11. **Report** — On a weekly cadence (or first short digest sooner), operator sees interaction counts, top intents, and gaps (“agents asked about warranty; you have no answer”).
|
||||
|
||||
---
|
||||
|
||||
## 6. Alternate paths
|
||||
|
||||
| ID | Trigger | Behavior |
|
||||
|----|---------|----------|
|
||||
| A1 | Operator is non-technical | Portal emphasizes one-click copy steps; offers partner handoff without blocking signup |
|
||||
| A2 | Website is nearly empty | Simulation still runs from portal-entered data; scrape reflection shows hard gaps; go-live may be limited until minimum content exists |
|
||||
| A3 | No online booking yet | Fulfillment path degrades to “call/book link pending”; portal prioritizes installing Cal.com (or peer) rather than inventing a booking engine |
|
||||
| A4 | Delegate implements pointer | Owner still owns account; delegate gets install instructions only |
|
||||
| A5 | Promo content changes (e.g. July 4 oil-change special) | Owner updates site or portal fields, re-runs preflight, confirms special appears in test harness |
|
||||
|
||||
---
|
||||
|
||||
## 7. Exception paths
|
||||
|
||||
| ID | Trigger | Behavior |
|
||||
|----|---------|----------|
|
||||
| E1 | Preflight fails repeatedly | Block “fully live” status; show ranked fixes; do not claim AI-ready |
|
||||
| E2 | Pointer installed on wrong domain | Detect mismatch; fail preflight with plain-language error |
|
||||
| E3 | Chronic low helpfulness after go-live | Quality loop opens coaching; after threshold, endpoint can be quarantined or decommissioned (see strategy quality rules) |
|
||||
| E4 | Business is not local service | Soft reject or route out of ICP during genre/identity step |
|
||||
|
||||
---
|
||||
|
||||
## 8. Functional requirements (product)
|
||||
|
||||
- Genre-aware onboarding for auto repair
|
||||
- Site scrape + human-readable reflection
|
||||
- Simulation that is obviously about *external* AI, not “your new chatbot”
|
||||
- Multi-path pointer generation (not a single fragile convention)
|
||||
- Live MCP preflight in browser
|
||||
- Editable structured profile (services, specialty, hours, booking link, story)
|
||||
- Reporting of agent interactions and failed questions
|
||||
- Partner referral option when site work exceeds self-serve
|
||||
|
||||
## 9. Data the MCP must support for this genre (minimum)
|
||||
|
||||
- Identity and location
|
||||
- Hours
|
||||
- Services list with plain-language descriptions
|
||||
- Specialization signals (e.g. transmissions, European/Korean makes)
|
||||
- Booking path (link or orchestrated booking later)
|
||||
- Story / trust copy (owner, tenure, guarantees if present)
|
||||
- Optional: emergency vs scheduled, estimate vs fixed-price notes
|
||||
|
||||
Exact schema lives in engineering; this list is the product contract for “auto pack v1.”
|
||||
|
||||
---
|
||||
|
||||
## 10. Success metrics
|
||||
|
||||
| Metric | Definition | Early target |
|
||||
|--------|------------|--------------|
|
||||
| Time to first preflight | Signup → first live MCP test | Under 30 minutes for a motivated operator |
|
||||
| Preflight pass rate | Share of signups that pass critical checks within 7 days | Track; improve weekly |
|
||||
| Pointer verified | Discovery attachment confirmed live | Required for “live” badge |
|
||||
| Weekly active endpoints | Live endpoints with ≥1 agent or preflight interaction | Leading indicator |
|
||||
| Owner-reported clarity | “I understand what this does” after simulation | Qualitative; interview first 20 |
|
||||
|
||||
---
|
||||
|
||||
## 11. Out of scope for UC-01
|
||||
|
||||
- Building a consumer marketplace or destination site
|
||||
- Replacing the shop’s booking vendor
|
||||
- Full SEO agency services
|
||||
- Multi-location franchise admin
|
||||
- Guaranteeing a specific assistant will recommend the shop (we make them recommendable; engines still choose)
|
||||
- Model 2 intermediate aggregation (see UC-02)
|
||||
|
||||
---
|
||||
|
||||
## 12. Dependencies
|
||||
|
||||
- HTTP multi-tenant MCP
|
||||
- Ingestion/scrape pipeline
|
||||
- Portal application
|
||||
- Auto-repair genre pack v1
|
||||
- Cal.com (or equivalent) for fulfillment path
|
||||
- Quality policy for quarantine/decommission
|
||||
|
||||
---
|
||||
|
||||
## 13. Open questions
|
||||
|
||||
1. Minimum content bar before “live” vs “limited live”?
|
||||
2. Which pointer formats do we support on day one vs later?
|
||||
3. Do we require booking link for go-live, or only for “bookable” badge?
|
||||
4. Who performs first decommission decision — product ops rule or human review only?
|
||||
Reference in New Issue
Block a user