Ty_Tech/geolocal-io
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
1e66fe135aa07d2ba15c046446a15a6c7cd88b65
geolocal-io/docs/product/use-cases/uc-01-endpoint-auto-repair.md
T
VPS admin 9478aaa22e 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
2026-07-18 06:00:26 +00:00

7.7 KiB
Raw Blame History

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 View Git Blame Copy Permalink