geolocal-io/docs/product/use-cases/uc-02-intermediate-tourism-board.md

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 20–100 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	20–100
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 board’s 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?