geolocal-io/docs/product/use-cases/uc-01-endpoint-auto-repair.md

# 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?