Files
geolocal-io/docs/product/use-cases/uc-02-intermediate-tourism-board.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

161 lines
8.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# UC-02 — Intermediate activation: destination tourism board
**Status:** Spec
**Business model:** Model 2 — Intermediate enablement
**Primary surface:** Intermediate MCP + member onboarding (reuses Model 1 endpoint mechanics)
**Priority:** P1 for full dashboard; pilot can start as soon as Model 1 endpoints exist
---
## 1. Problem
A destination tourism board (example: a coastal city visitor bureau funded partly by lodging tax) is supposed to promote local experiences and member businesses. In practice, its website is a human-readable brochure: lists, categories, PDFs, event calendars. AI assistants treat that class of site as a **weak discovery surface** — useful for confirming that a place or business exists, weak for evaluating specialization, availability, or booking.
The board has budget it is expected to spend on promotion, and often limited internal confidence about how to spend it for the AI era. Member businesses pay dues and still remain invisible to assistants. The brochure rack in the hotel lobby still does more immediate work than the website does for agentic visitors.
---
## 2. Desired outcome
The board can:
1. Stand up a **destination-level MCP** that helps assistants understand the place and route to member services
2. Onboard a first cohort of members onto geolocal endpoints (directly or via staff/partners)
3. See simple evidence of value: member attach rate, agent hits, category demand
4. Justify the pilot against lodging-tax / visitor-experience goals
5. Convert members from pilot access to paid endpoints over time
The board stops being only a link list and becomes a **high-signal intermediate** in the AI discovery and evaluation path.
---
## 3. Actors
| Actor | Role |
|-------|------|
| **Board director / marketing lead** | Buyer; cares about destination performance and politics of members |
| **Board staff** | Day-to-day member onboarding and content hygiene |
| **Member business** | Local service or experience provider (charter, bike rental, repair, spa, etc.) |
| **Visitor** | Consumer asking an assistant for things to do / local help while traveling |
| **AI assistant** | External engine using intermediate + member signals |
| **geolocal platform** | Intermediate MCP, member endpoints, reporting |
---
## 4. Preconditions
- Board has authority (or pilot permission) to run a technology pilot for members
- Identifiable first verticals or member shortlist (e.g. charters, activities, essential services)
- Ability to communicate with members (email list, meetings, onboarding workshop)
- geolocal can host member endpoints (UC-01 mechanics available, even if rough)
- Legal: basic pilot terms and data use understanding
---
## 5. Main success scenario
1. **Pilot framing** — Board agrees the goal is AI visitor helpfulness and member discoverability, not “another directory redesign.”
2. **Destination profile** — Staff provide place identity, priority categories, seasonal notes, and member list.
3. **Intermediate MCP live** — Platform exposes a destination endpoint assistants can use to understand the place and list structured member options by category.
4. **Member cohort invite** — Board invites 20100 members into onboarding (workshop, email, or staff-assisted).
5. **Member activation** — Each member completes UC-01-style activation (scrape, pointer, preflight) with destination context pre-associated.
6. **Aggregation** — Intermediate MCP only surfaces members that meet minimum quality/live bars (not every unpaid legacy listing by default).
7. **Visitor path** — A visitor asks an assistant for a charter, e-bike rental, or emergency phone repair in the destination; assistant can use intermediate signal and/or member MCP rather than a thin brochure page alone.
8. **Board reporting** — Dashboard (or pilot report) shows members live, category coverage, interaction counts, and top unmet intents.
9. **Conversion** — After pilot window, members move to paid tiers; board retains intermediate subscription or partnership terms.
10. **Expansion** — Board adds categories or a second wave of members; quality bar remains enforced.
---
## 6. Alternate paths
| ID | Trigger | Behavior |
|----|---------|----------|
| A1 | Board wants white-glove only | Staff or geolocal-assisted onboarding for first cohort; self-serve still available |
| A2 | Chamber of commerce instead of tourism board | Same intermediate pattern; funding story shifts from lodging tax to member value / economic development |
| A3 | Members already on booking platforms | Keep those booking paths; intermediate still supplies discovery/evaluation structure |
| A4 | Low technical capacity at board | Start with spreadsheet-fed member import + staff login; full dashboard later |
---
## 7. Exception paths
| ID | Trigger | Behavior |
|----|---------|----------|
| E1 | Member fails preflight | Exclude from intermediate “recommended” set until fixed; still visible to staff as incomplete |
| E2 | Member harms destination helpfulness | Quarantine from intermediate aggregation; board notified |
| E3 | Political pressure to list everyone regardless of quality | Product keeps a “directory dump” mode separate from “AI-recommended set”; do not poison the high-signal path |
| E4 | Procurement delay | Keep SMB self-serve in market; treat board as parallel track, not a gate on all GTM |
---
## 8. Functional requirements (product)
- Destination (intermediate) entity with categories and member associations
- Intermediate MCP tools: place overview, category browse, member resolve, seasonal notes
- Member onboarding that reuses endpoint activation
- Quality gating between “listed” and “AI-ready / aggregated”
- Board-facing report or dashboard: attach rate, hits, intents, gaps
- Pilot-friendly admin (invite, status, export)
## 9. What the intermediate MCP must do (minimum)
- Answer “what is this place good for?” in structured form
- List live members by category with deep links to member MCP identity
- Avoid inventing services the member cannot support
- Prefer members with passing preflight and fresh data
- Expose contact/booking paths only when member endpoint provides them
The intermediate is a **bridge with signal**, not a second Yelp and not a passive HTML list.
---
## 10. Success metrics
| Metric | Definition | Early pilot target |
|--------|------------|--------------------|
| Members invited | Cohort size | 20100 |
| Members live | Passed critical preflight + pointer verified | ≥40% of invited within pilot window |
| Intermediate queries | Agent or test harness hits on destination MCP | Weekly growth |
| Category coverage | Priority categories with ≥1 live member | Board-defined must-have set complete |
| Board satisfaction | Willingness to renew / expand | Explicit yes/no at pilot review |
| Member conversion | Live members → paid after pilot | Track; optimize after first pilot |
---
## 11. Out of scope for UC-02
- Replacing the boards full CMS or membership CRM
- Building a consumer destination marketplace branded as geolocal
- Guaranteeing tourism lift numbers in season one
- National multi-board enterprise packaging before one pilot works
- Owning lodging, flights, or car rental (Airbnb/Kayak space)
---
## 12. Dependencies
- UC-01 endpoint activation working for at least one tourism-relevant genre
- Intermediate MCP routing and aggregation rules
- Pilot agreement template (legal)
- Reporting (even CSV/manual is acceptable for first pilot)
- Quality policy shared with Model 1
---
## 13. Funding and sales notes (GTM, not engineering)
- Pitch against **mandated or expected promotion spend**, not against random software budget
- Language: visitor experience, member value, AI-era discoverability, stewardship of lodging-tax intent
- Proof: before/after member AI-readiness and intermediate query evidence
- Risk to name honestly: procurement speed; mitigate with short pilot and parallel SMB motion
---
## 14. Open questions
1. First destination market(s)?
2. Does the board pay, members pay, or both during pilot?
3. Hard quality gate for aggregation from day one, or soft gate with warnings?
4. Branding: geolocal-powered vs fully white-labeled board experience for v1?