- 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
Near-term execution question: what can we ship in the next 30 days that proves Model 1 (HTTP MCP + portal spine + real pilot endpoints) and starts a destination pilot conversation?
Near-term execution: ship Priority 0 platform (HTTP MCP, ingestion, first genre pack, portal spine, real endpoints) and open one destination pilot conversation — without confusing the portal for the whole company.
Assistants evaluate helpfulness partly by whether the business answers the *right* questions for its category. “Do you work on Korean transmissions?” is not the same shape as “Do you have a sunset charter tomorrow for six?”
## Repo note (future)
Genre packs will live under top-level `genres/` in a later monorepo phase. Product intent is documented here first.
Genre packs will live under top-level `genres/` in a later monorepo phase. Product intent and use-case contracts stay here first.
Model 2: destinations and membership organizations as discovery nodes.
Model 2: destinations and membership organizations as discovery and evaluation nodes.
## Intent
One intermediate relationship should bring many member endpoints online. Boards get an aggregating MCP, member onboarding (via SSP patterns), and a simple dashboard of hits and category demand. Funding often sits in lodging-tax or destination marketing budgets.
Today, assistants often treat these sites as low-signal link lists. We upgrade them into structured intermediate MCPs backed by live member endpoints. One intermediate relationship should bring many members online and create a funding path through lodging-tax or destination-promotion budgets.
## Detail source
## Spec source of truth
[Canonical Strategy](../strategy/CANONICAL_STRATEGY.md) (§4 Model 2, §7 GTM wedge).
geolocal.io ships **AI-readiness infrastructure** for local services: hosted multi-tenant MCP, a discovery pointer on the business site, the Self-Service Portal, intermediate (destination/chamber) surfaces, and later telemetry and graph products.
geolocal.io is **AI-readiness infrastructure** for local services. Assistants call structured endpoints. Businesses own their presence. Intermediates and partners help distribution. Booking and payments are orchestrated through specialists, not rebuilt here.
See [Canonical Strategy](../strategy/CANONICAL_STRATEGY.md) sections 4–5 for the full product definition and the four business models.
We barely try to own pure discovery SEO. We are primary for evaluation, selection, and complementary fulfillment, and second chair for interpretation and feedback. Detail: [Canonical Strategy §5](../strategy/CANONICAL_STRATEGY.md).
## Related
- [genre-packs.md](./genre-packs.md)
- [ssp.md](./ssp.md)
- [intermediate.md](./intermediate.md)
-[genre-packs.md](./genre-packs.md)
-Engineering priorities in the strategy, roadmap under `docs/engineering/`
Primary product experience for individual local businesses (Model 1).
Activation experience for individual local businesses (Model 1). Important, not the whole company.
## Intent
Owners should feel the value before they pay: genre-aware onboarding, site scrape reflection, a live simulation of an AI recommending and booking them, pointer install, in-browser preflight against their MCP, optimization guidance, optional partner handoff, and ongoing reports.
Owners should feel the value before they pay: genre-aware onboarding, site scrape reflection, a live simulation of an external AI recommending and booking them, pointer install, in-browser preflight against their MCP, optimization guidance, optional partner handoff, and ongoing reports.
The portal chat UI is a **test harness** for how *external* AI assistants will interpret the business — not a customer-facing chatbot we sell as the product.
The portal chat UI is a **test harness** for how external assistants will interpret the business — not a customer-facing chatbot product.
## Detail source
## Spec source of truth
Full narrative and priorities: [Canonical Strategy](../strategy/CANONICAL_STRATEGY.md) (§5 Self-Service Portal, §10 priorities).
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 |
- 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).
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)
**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?
**Status:** Final draft (2026-07-18) — functionally on point; expect incremental alterations as we progress.
**Status:** Final draft (2026-07-18; revised same day to restore full strategic depth)
**Role:** The document the team plans, builds, and sells against. When other docs disagree with this one, update them — or update this one deliberately. Do not leave the conflict hanging.
This is an operating strategy, not a product brochure. The Self-Service Portal matters, but it is one activation surface. The company is the platform underneath.
---
## 1. What we are
geolocal.io is the infrastructure that lets local service businesses show up properly inside the AI era — discoverable, understandable, bookable, and measurable when someone asks ChatGPT, Claude, Gemini, or the next assistant for a plumber, a transmission shop, a fishing charter, or a place to rent bikes.
geolocal.io is the infrastructure that lets local service businesses show up properly inside the AI era — discoverable, understandable, bookable, and measurable when someone asks an assistant for a plumber, a transmission shop, a fishing charter, or a place to rent bikes.
We are not building another place for consumers to browse. We are not selling business owners a chatbot for their website. We are not trying to replace Yelp or Google as destinations people open on purpose.
@@ -19,116 +21,213 @@ We are the layer underneath. AI agents call us. Businesses own their presence. T
### Consumers already changed behavior
A large and growing share of people now ask AI tools for local recommendations. BrightLocal’s 2026 consumer research puts that figure around 45%, with ChatGPT as the most common tool people name. Earlier surveys used different wording and showed much smaller numbers (around 6% in some 2025 reporting), so we should treat the leap as real without pretending every percentage point is apples-to-apples in investor decks.
A large and growing share of people now ask AI tools for local recommendations. BrightLocal’s 2026 consumer research puts that figure around 45%, with ChatGPT as the most common tool people name. Earlier surveys used different wording and showed much smaller numbers, so we should treat the leap as real without pretending every percentage point is apples-to-apples in investor decks.
What matters operationally is the shape of the answer. AI does not hand you a page of blue links. It names one, two, or three businesses. If you are not one of those names, you do not exist in that moment. Practitioners talking about this on the open web describe the same thing: local discovery is collapsing into a shortlist of recommendations, not a results page.
What matters operationally is the shape of the answer. AI does not hand you a page of blue links. It names one, two, or three businesses. If you are not one of those names, you do not exist in that moment.
### AI is extremely selective about who it recommends
SOCi’s 2026 Local Visibility Index looked at roughly 350,000 locations across more than 2,700 multi-location brands. In that sample, ChatGPT recommended only about 1.2% of brand locations. Gemini and Perplexity were higher (around 11% and 7%) but still far below traditional Google local 3-pack visibility (around 36%). Locations that do get recommended tend to look trustworthy — ChatGPT’s picks averaged about 4.3 stars.
Other local SEO research has also found that AI systems lean hard on listings and review sources. Yelp, for example, shows up frequently as a cited source in local answers. That is good news for platforms that already own data. It is bad news for the independent shop whose only online presence is a dusty website and a half-maintained Google listing.
SOCi’s 2026 Local Visibility Index looked at roughly 350,000 locations across more than 2,700 multi-location brands. In that sample, ChatGPT recommended only about 1.2% of brand locations. Gemini and Perplexity were higher but still far below traditional Google local 3-pack visibility. Locations that do get recommended tend to look trustworthy — high ratings, complete profiles, consistent signals.
Traditional local SEO still matters. It is no longer enough. Businesses need a machine-readable, up-to-date, bookable expression of who they are.
### The big platforms are building for themselves
### The long tail is last again
This is the structural opening.
Shopify has already shipped Storefront MCP on merchant domains so agents can search catalogs, manage carts, and move toward checkout without scraping a site. Yelp has published an official MCP path into its own Fusion AI data. Google is wiring MCP into Maps grounding and Merchant tooling and has partnered on open commerce protocols. Cal.com already exposes a serious booking MCP — create, reschedule, cancel, availability — so scheduling is not a greenfield problem.
What none of them are building is a neutral, business-owned on-ramp for the long tail of local services: Bob’s Garage, the surf shop, the charter captain, the salon, the tourism board that wants its members to be helpful to visitors’ AI assistants.
Incumbents protect their platforms and their datasets. We build the missing infrastructure for everyone else.
Service-oriented local businesses are poorly positioned for this shift. The pattern rhymes with the early web: platforms and structured commerce move first; independent brick-and-mortar catches up late, if at all. Airline, hotel, rental-car, and large e-commerce players are already investing in agent-ready experiences. Bob’s Garage is not.
---
## 3. North Star
## 3. How AI actually finds local businesses today
This section is load-bearing. Product and GTM only make sense if we respect how assistants really build a shortlist.
### Different engines, different substrates
Major assistants do not share one local-business brain. Each leans on a preferred retrieval substrate, then blends search and reasoning:
| ChatGPT | Yelp-style business/review data + search | Strong where Yelp is strong; weak for unlisted long-tail shops |
| Gemini | Google Business Profile, Maps, Knowledge Graph | Strong where GBP is complete; Google-centric fulfillment bias |
| Claude | Sparse POI data (historically Foursquare-class) + search | Often thinnest local coverage; more reasoning over incomplete data |
| Copilot-class systems | Search-first (e.g. Bing index) + tools | Depends heavily on what the open web makes legible |
On top of that, all of them still use general search, schema, and whatever tools or plugins are available. The strategic point is not the brand names of the datasets. The point is **fragmentation**: a local business can be invisible because it is missing or weak in the substrates the engines actually trust.
### From intent to shortlist to the real website
Roughly, the pipeline looks like this:
1. User states a need.
2. The engine interprets category, place, urgency, and constraints.
3. It retrieves candidates from its preferred substrate plus search.
4. It narrows to a shortlist.
5. For the serious candidates, it often loads or re-checks the actual website and any structured endpoints it can find.
6. It evaluates which option is most helpful — not merely most popular.
7. It tries to fulfill (book, call path, pay, confirm).
8. Over time it reinforces paths that worked.
That middle stretch is where long-tail businesses die. A Wix site from 2005 with a few photos and a phone number may be “a website,” but it is a poor helpfulness surface. Specialization is buried. Services are ambiguous. Booking is a phone tag. Pricing is a shrug. Engines notice.
### Helpfulness and repeatability
Relevance gets you considered. Helpfulness is why an assistant comes back. Helpfulness includes clear services, real specialization, honest pricing signals, availability, a clean booking path, and trust cues. When an engine finds a path that works repeatedly, it prefers that path next time. Our job is to make geolocal-backed businesses the path of least resistance for helpfulness.
---
## 4. North Star
Make AI give the most relevant and helpful recommendation for a local service need — and then fulfill it.
Relevance gets you on the shortlist. Helpfulness is why the assistant comes back next time. Helpfulness means clear services, real specialization, honest pricing signals, real availability, a clean booking path, trust cues, and a track record of successful outcomes. When an AI finds a path that works repeatedly, it prefers that path. Our job is to make geolocal-backed businesses the path of least resistance for helpfulness.
We stay focused on local service businesses. We are not trying to boil the ocean of all commerce.
---
## 4. Four business models (keep them distinct)
## 5. Where we sit in AI-first commerce
This company is not one product with one customer. It is four stacked models that reinforce each other. Earlier planning materials mostly described the first one. That is part of why the project felt fractured. All four stay in view.
Think of AI-first consumption as seven stages:
1.**Intent** — the user says what they need
2.**Interpretation** — the AI turns that into category, constraints, place, urgency
3.**Discovery** — candidates enter the pool
4.**Evaluation** — which options are clear, specialized, available, trustworthy, bookable
5.**Selection** — the assistant names the winner(s)
6.**Fulfillment** — book, schedule, pay, confirm
7.**Feedback** — the system learns what worked
### Our chair (be disciplined about this)
| Stage | Our role | Notes |
|-------|----------|--------|
| Intent | None | User-driven |
| Interpretation | Second chair | We shape interpretation by exposing clean attributes and genre primitives |
| Discovery | Light touch | We enable attachment and intermediate signal; we do **not** try to own SEO/GEO as a product |
| Selection | Primary | Become the tie-breaker for helpfulness |
| Fulfillment | Primary, complementary | Orchestrate booking/payment partners; do not rebuild Calendly, Square, or Stripe |
| Feedback | Second chair | Telemetry and quality loops reinforce good paths and remove bad ones |
If we drift into “we are an SEO company” or “we are a booking company,” we lose the plot.
### What “as-built” looks like for SMBs in 2026
When engines judge helpfulness, three dependency areas keep showing up:
1.**Website** — can a machine understand what this business does?
2.**Communication** — can a customer or agent complete a conversation path?
3.**Booking and payments** — can the job actually get scheduled and paid?
Some vendors in those lanes will grow their own MCPs (scheduling tools, salon platforms, POS systems). That is fine and expected. Those MCPs are usually **scenario-specific** — book a slot, take an order. They do not solve long-tail story, genre depth, destination aggregation, or a neutral business-owned presence that works across assistants. We complement them.
---
## 6. Four business models (keep them distinct)
This company is not one product with one customer. It is four stacked models that reinforce each other.
### Model 1 — Endpoint enablement
Individual small businesses attach to geolocal. They get a hosted multi-tenant MCP, a tiny pointer on their own website, a self-service portal, diagnostics, and ongoing reports. This is day-zero product.
Individual small businesses attach to geolocal. They get a hosted multi-tenant MCP, a discovery pointer on their own site, portal tools to activate and test, diagnostics, and reports.
### Model 2 — Intermediate enablement
Tourism boards, chambers of commerce, and visitor bureaus become discovery nodes. They get an aggregating MCP for a destination or membership set, tools to onboard members, and a story they can take to leadership about visitor experience and economic development. This is our primary go-to-market wedge for scale.
Tourism boards, chambers of commerce, and visitor bureaus become better discovery nodes. Today, AI often treats those sites as **weak link aggregators**: useful for existence and category, weak for evaluation and fulfillment. We upgrade them into structured, member-backed MCP surfaces that actually help assistants choose and complete.
### Model 3 — Industry trust layer
Over time, quality norms, genre standards, and decommissioning of bad data make geolocal a surface AI systems learn to prefer. This is not a year-one revenue line so much as the strategic prize of doing Models 1 and 2 well.
Over time, quality norms, genre standards, and decommissioning of bad data make geolocal a surface AI systems learn to prefer. This is the strategic prize of doing Models 1 and 2 well, not a year-one slideware line.
### Model 4 — Service graph
Once enough endpoints and intermediates exist, the network itself becomes valuable: related businesses, specialties, demand patterns, competitive context. Think of an AI-native successor to the old local directory graphs — not a consumer portal, but infrastructure and data products built on real usage.
Once enough endpoints and intermediates exist, the network itself becomes valuable: related services, specialties, demand patterns, competitive context. An AI-native successor to old local directory graphs — infrastructure and data products built on real usage, not social check-ins.
**Operating rule:** Every product decision should name which model it serves. We do not build Model 4 features before Models 1 and 2 are real.
---
## 5. What we actually sell
## 7. Product definition
### The offer
### Platform first
We sell AI-readiness infrastructure for local services. In practice that means:
What we actually sell is **AI-readiness infrastructure for local services**:
1.**A hosted multi-tenant MCP**that agents can call for structured business truth — story, services, hours, booking path, related businesses, and later genre-specific detail.
2.**A dead-simple discovery pointer** on the business’s own site (for example a well-known path or JSON file) that points at us. No servers for Bob’s daughter to manage. Pattern-wise, this is the same idea as Shopify putting MCP on the merchant domain while hosting the hard parts.
3.**A Self-Service Portal** — the real product experience for owners (described below).
4.**Orchestration, not reinvention.** Cal.com for booking. Stripe for payments. We integrate; we do not rebuild their categories.
5.**Telemetry and optimization reports** — how often agents hit you, what they asked for, where your site or data failed, and what demand looks like in your area.
6.**Surfaces for partners and intermediates** — agencies, SEO consultants, tourism boards, chambers.
1.**Hosted multi-tenant MCP**— structured tools agents call for story, services, hours, specialization, booking path, related businesses, and genre-specific detail.
2.**Discovery attachment on the business domain** — not a single magic path only. Industry precedent is already multi-location and extensible (`/mcp`, commerce-style paths, AI context paths, well-known files). Those locations can point **off-domain** to hosted infrastructure such as geolocal. That extensibility is what makes “easy for Bob’s daughter” possible.
3.**Ingestion and content sync** — a strong channel from the business’s public content into the MCP. Garbage in, garbage out. If the source site cannot support helpful answers, the portal and reports have to say so.
4.**Genre packs** — vertical primitives. A salon MCP is not identical to a phone-repair MCP, even if some tools overlap.
5.**Orchestration of fulfillment partners** — Cal.com (and peers) for booking, Stripe (and peers) for payment. We integrate; we do not rebuild those categories.
6.**Telemetry and owner insight** — not vanity dashboards. Concrete helpfulness feedback: what agents asked, where they bounced, how the business compares to category peers, what to change.
7.**Quality enforcement** — including the right to **decommission** chronically harmful endpoints. Bad data does not only hurt one customer; it taxes the trust of the whole network with AI engines.
8.**Intermediate surfaces** — destination and chamber MCPs plus operator dashboards.
9.**Activation UX** — Self-Service Portal for owners; partner flows for people who implement for them.
### The Self-Service Portal
### Self-Service Portal — important, not the whole company
For a typical small business, the portal is how the product clicks.
The portal is how Model 1 becomes self-serve at scale. It is a **small but critical corner** of the whole concept.
They come to geolocal.io and describe the business. The experience adapts to the genre — automotive feels different from a surf shop or a charter. We scrape their existing site and show them what the system already sees. Then we put a phone-and-chat style simulation in front of them: an assistant recommending their shop, listing real services, and finding a Thursday-at-three slot for the job they actually do. That is the aha moment. They are not buying abstract “AI optimization.” They are watching pre-qualified, in-scope, calendar-aligned demand show up.
Owners come to geolocal.io, describe the business, and the experience becomes genre-aware. We scrape and reflect what we already see. We show a visual simulation of an assistant recommending them, listing services, and finding a real appointment path. They install a tiny pointer. They run a preflight against their live MCP. They get upstream guidance (get found) and downstream guidance (be understandable and bookable). They can choose self-serve fixes or a local partner. They receive ongoing reports.
To make that real, they install a tiny pointer on their site. We walk them through a preflight test in the browser against their live MCP. If the assistant cannot see services, hours, or specialty, they fix content or portal data before going live. We also give upstream guidance (how to get found in the first place — Google Business Profile, consistent NAP, plain-text city and service language, FAQs) and downstream guidance (how to keep the MCP helpful). If they need website help, we can introduce a partner. After launch, they get regular reports on interactions, intents, and local demand.
One line we will not blur: **we are not selling them a chatbot for their customers.** The chat UI inside the portal is a test harness so the owner can see how *external* assistants will interpret the business. That distinction matters for product, pricing, and sales language.
One line we will not blur: **we are not selling them a customer chatbot.** The chat UI in the portal is a test harness so the owner can see how *external* assistants interpret the business — including how a July 4th oil-change special should appear, logos and details included.
### Genre-specific primitives
A generic “get business info” tool is fine for scaffolding. The durable product is genre systems — structured fields and tools that match how a category actually works.
Generic “get business info” is scaffolding. Durable differentiation is genre systems:
- Auto: makes and models, specialties, emergency flags
- Beauty: services, duration, stylist context
- Home services: service radius, emergency vs scheduled, estimate vs fixed price
- Intermediates: member directory and category routing for a destination or chamber
- Intermediates: member directory and category routing
Roadmaps should ship **genre packs**, not only generic endpoints.
Roadmaps ship **genre packs**, not only generic endpoints.
### What we will not build in the near term
We are not a consumer destination app. We are not competing with Calendly, Cal.com, or Square as booking engines. We are not competing with Stripe or Square as payment rails. We are not replacing Google Business Profile. We are not building a Yelp-style review network. We are not trying to out-Kayak Kayak or out-Airbnb Airbnb. Stay complementary to travel platforms; own the local service long tail they do not serve cleanly for AI agents.
Upstream SEO/GEO checklists and partner referrals exist so businesses can *be found*. That work is enablement, not our core product category.
---
## 6. How we talk about ourselves
## 8. Trust, quality, and operations (table stakes)
If AI engines are going to rely on us for evaluation and fulfillment, we have to look like infrastructure they can trust — closer to Shopify or Stripe in operational posture than to a weekend plugin.
**Assumed bar for anything we claim is production:**
- Regional hosting and sensible data locality
- High availability and graceful failure modes
- Compliance posture appropriate to what we touch (privacy always; payments-grade controls if we handle payment data directly)
- Strict, versioned schemas and deterministic tool behavior
- Structured errors, rate limits, and clear retry semantics
- Authentication and integrity on sensitive surfaces
5. If a business remains chronically harmful to collective helpfulness, **decommission** or quarantine the endpoint.
That last step is uncomfortable and necessary. Model 3 depends on it.
---
## 9. Positioning
### Category
AI-readiness infrastructure for local services — or, when you need a shorter phrase, agentic local commerce infrastructure.
AI-readiness infrastructure for local services — or, shorter, agentic local commerce infrastructure.
### Analogies that help
- **Shopify Storefront MCP for local services** — usually the clearest one-liner for technical and product people.
- **Stripe for AI discovery and booking presence** — useful when you need “infrastructure, not another app UI.”
- **Twilio for local service tools** — agents call a contract; the business does not rebuild a stack.
- **Shopify Storefront MCP for local services** — usually the clearest one-liner
- **Stripe for AI discovery and booking presence** — infrastructure, not another consumer app
- **Service registry for the long tail** — 2028 language when talking to platforms and sophisticated partners
### Messaging that works
@@ -139,83 +238,97 @@ AI-readiness infrastructure for local services — or, when you need a shorter p
### Language to avoid
Do not call this an AI chatbot for the website. Do not claim we replace Google or Yelp. Do not position primarily as “an SEO tool with AI features,” even though discovery guidance is part of the portal. Category is infrastructure.
Do not call this an AI chatbot for the website. Do not claim we replace Google or Yelp. Do not position primarily as an SEO tool with AI features.
---
## 7. Go-to-market
## 10. Go-to-market
### Primary wedge: tourism and destination intermediates
Hotel and lodging taxes create promotion budgets that destinations are often required to spend. Boards and visitor organizations frequently struggle to spend that money well, and many run open calls for ideas. One intermediate relationship can bring dozens or hundreds of member endpoints online at once. Travel is also an area where AI referral behavior has been growing quickly in industry reporting. The brochure rack in the hotel lobby is the analog world proving the job to be done; geolocal is the AI-native version of that job.
Hotel and lodging taxes create promotion budgets that destinations are often required to spend. Boards frequently struggle to spend that money well and sometimes openly solicit ideas. One intermediate relationship can bring many member endpoints online. The brochure rack in the hotel lobby is the analog world proving the job to be done; we are the AI-native version of that job.
Technically, the sale is not “another directory listing.” It is: **stop being a low-signal link list; become a high-signal MCP for your place and your members.**
Motion:
1. Choose one or two destination markets for a real pilot.
2. Sell a board-level pilot: destination MCP, member onboarding through the portal, and a simple dashboard of member hits and category demand.
3. Fund it with tourism marketing budgets, innovation RFPs, or “AI visitorexperience” framing — whatever matches how that board already buys.
2. Sell a board-level pilot: destination MCP, member onboarding, simple demand and hit reporting.
3. Fund it with tourism marketing budgets, innovation RFPs, or visitor-experience framing.
4. Give members free or discounted endpoints during the pilot, then convert to paid.
### Parallel motion: self-service small businesses
While intermediates mature, we also sell direct. First genre packs should be high-intent local services — auto repair, beauty, home services — and tourism activities when a destination pilot needs them.
While intermediates mature, sell direct into high-intent verticals — auto repair, beauty, home services — and tourism activities when a destination pilot needs them.
Pricing direction for self-serve (infrastructure framing, not chatbot usage):
### Partners as distribution
| Tier | Monthly | Intent |
|------|---------|--------|
| Starter | about $49 | Endpoint, portal test experience, monthly report, basic diagnostics |
| Core | about $129 (anchor) | Full MCP, live preflight, weekly reports, local demand insights, partner access |
| Pro | about $249 | Multi-site, deeper telemetry, competitor signals, priority support |
Position above DIY chat widgets and below enterprise multi-location AI visibility platforms. Tourism board deals use separate pilot or enterprise pricing, not the SMB price list.
### Partners as distribution, not the product
Agencies, SEO shops, and local web people matter. They are how hard websites get fixed and how busy owners get onboarded. They are not the center of the product story. The portal offers self-serve or “talk to a partner.” Commission and wholesale terms come after we have real attach volume — roughly after the first fifty to a hundred endpoints.
Agencies, SEO shops, and local web people matter for hard websites and busy owners. They are distribution and implementation, not the center of the product story.
### Where we will not lead
We do not lead with national multi-location brand AI visibility (that is a different buyer and a different set of competitors). We do not lead with pure e-commerce (Shopify already owns that MCP story). We do not lead with pure B2B or non-local use cases.
We do not lead with national multi-location brand AI visibility software. We do not lead with pure e-commerce. We do not lead with pure B2B or non-local use cases. We do not try to plant a blackjack table on the Las Vegas sidewalk of Airbnb/Kayak.
---
## 8. Competitive posture
## 11. Competitive posture
### How the vacuum gets filled — and our answer
### How the vacuum gets filled
All vacuums get filled — by outsiders or by incumbents. The question is who, when, and how.
| Actor | Likely path | Our response |
|-------|-------------|--------------|
| Yelp | Become a default AI source of local truth via MCP and data licensing | Offer business-owned truth and a booking path the business controls; stay complementary when agents need owner data Yelp cannot provide |
| Google | Maps, Merchant, and open commerce protocols | Stay complementary; help owners with Business Profile hygiene; do not fight Maps for consumer UI |
| Shopify | Keep expanding agentic commerce | Copy the good patterns (merchant-domain discovery, hosted complexity); do not compete for e-commerce |
| Cal.com, Square, Vagaro | Booking and ops MCPs | Integrate deeply; own discovery, genre, intermediates, and graph |
| AI visibility SaaS for big multi-location brands | Measure and optimize enterprise footprints | Different customer; we own long-tail endpoints and destination distribution |
| Local agencies | Manual “get recommended by AI” retainers | Make them partners; productize what they cannot scale alone |
| Yelp | Default AI source of local truth via data + MCP | Business-owned truth and booking path the owner controls |
| Google | Maps, Merchant, open commerce protocols | Complementary; help with GBP hygiene; do not fight Maps for UI |
| Shopify | Expand agentic commerce | Copy good discovery patterns; do not compete for e-commerce |
| Cal.com, Square, Vagaro | Booking and ops MCPs | Integrate; own discovery, genre, intermediates, graph, quality |
| AI visibility SaaS for big chains | Measure enterprise footprints | Different buyer |
| Local agencies | Manual “get recommended by AI” retainers | Partner channel |
### Moats, in the order we earn them
1. Endpoint density in specific geos and genres
2. Genre primitive quality that AI systems prefer because it is more helpful
3. Telemetry flywheel — demand signals improve recommendations, which attract more attach
2. Genre primitive quality that engines prefer
3. Telemetry and quality enforcement (including decommissioning)
4. Intermediate contracts that lock distribution
5. Trust and quality enforcement — freshness, decommissioning, reliability
5. Trust posture and operational reliability
6. Service graph effects after critical mass
Compared with older local graphs that depended on social check-ins, our freshness comes from the real service economy: availability, bookings, content updates, and agent interactions that do not dry up unless local commerce dries up.
Freshness comes from the real service economy — content updates, availability, bookings, agent interactions — not from social check-ins that dry up.
### 2026 to 2028
In the near term, engines are still learning which MCP patterns to trust. Over the next couple of years, structured endpoints become normal for commerce-like tasks. Businesses without machine-actionable presence get harder to recommend. Off-domain hosted MCPs become ordinary. The winners look less like “another SMB SaaS UI” and more like **registries and infrastructure** that assistants can rely on twice.
---
## 9. What success looks like
## 12. Pricing principles (SMB self-serve)
Infrastructure pricing, not chatbot usage pricing:
| Tier | Monthly | Intent |
|------|---------|--------|
| Starter | about $49 | Endpoint, portal test experience, monthly report, basic diagnostics |
| Core | about $129 (anchor) | Full MCP, live preflight, weekly reports, demand insights, partner access |
| Pro | about $249 | Multi-site, deeper telemetry, competitor signals, priority support |
Tourism board deals use separate pilot or enterprise pricing. Do not block launch on perfect price discovery.
---
## 13. What success looks like
### First 90 days
- Public multi-tenant MCP over HTTP (stdio alone is not a product agents on the open internet can use)
7. Intermediate (tourism) MCP and member aggregation
8. Board dashboard for members, hits, and categories
9. Pilot paperwork and data agreements
9. Intermediate (tourism) MCP and member aggregation
10. Board dashboard for members, hits, and categories
11. Pilot paperwork and data agreements
**Priority 2 — feed Models 3 and 4**
10. Telemetry pipeline and owner reports
11. Related businesses tool and quality rules
12. More genre packs
13. Partner marketplace
12. Stronger telemetry pipeline and owner reports
13. Related businesses tool and quality rules with real enforcement
14. More genre packs
15. Partner marketplace
**Explicitly later:** full white-label everywhere, heavy OAuth before we need it, a public developer platform, a full data-as-a-service product, and CMS plugins until attach volume demands them.
**Explicitly later:** full white-label everywhere, heavy OAuth before we need it, public developer platform, full data-as-a-service product, CMS plugins until attach volume demands them.
---
## 11. Risks we take seriously
## 15. Risks we take seriously
**Yelp or Google become “good enough.”**
We counter with business-owned data, booking completion, genre depth, intermediate distribution, and a clear owner-control story.
Counter with business-owned data, booking completion, genre depth, intermediate distribution, quality enforcement, and ownercontrol.
**Small businesses will not care until bookings prove ROI.**
The portal’s live simulation, tourism-funded pilots, demand reports, and partner-assisted installs exist to close that gap.
Portal simulation, tourism-funded pilots, demand reports, and partner installs exist to close that gap.
**MCP and discovery conventions will keep moving.**
Follow patterns the industry already recognizes (merchant-domain discovery, well-known locations, multi-path fallbacks). Do not invent a private religion.
**We over-index on the portal and under-build the platform.**
Weekly check: are we shipping registry-grade infrastructure, or only onboarding UI?
**Market statistics get oversold in the pitch.**
Cite sources carefully. Distinguish multi-location brand studies from the entire SMB universe. Prefer honesty over hype; the opportunity is large enough without exaggeration.
**MCP and discovery conventions keep moving.**
Support multi-path discovery; follow industry precedent; avoid private religion.
**Scope creeps into chatbots or consumer marketplaces.**
Weekly check: are we still infrastructure? If the answer is fuzzy, cut scope.
**Market statistics get oversold.**
Cite carefully. Distinguish multi-location brand studies from all SMBs.
**Engineering builds tools nobody can activate.**
No new MCP tool without a portal path that shows an owner why it matters.
**Bad endpoints poison trust.**
Measure helpfulness; coach; decommission when needed.
**Scope creeps into chatbots, SEO retainers, or consumer marketplaces.**
Return to the chair table in §5.
**Tourism procurement is slow.**
Run self-serve SMB in parallel. Prefer short pilot contracts over perfect enterprise RFPs for the first win.
Run self-serve SMB in parallel. Prefer short pilots over perfect RFPs for the first win.
---
## 12. How we keep the docs honest
## 16. Document governance
| Document | Job |
|----------|-----|
| `docs/archive/` | Historical exploration only — not the operating manual |
| **`docs/strategy/CANONICAL_STRATEGY.md` (this file)** | **Operating strategy the team rallies around** |
| `NORTH_STAR.md` | Short compass; must stay consistent with this file |
If two documents disagree, either this file changes on purpose or the other document changes. Silence is how the project fractures again.
If two documents disagree, resolve it on purpose.
---
## 13. Near-term leadership decisions
## 17. Near-term leadership decisions
1.Adopt this document as the single operating strategy (or mark specific sections for revision).
2.Rewrite `NORTH_STAR.md` so it reflects four models, the tourism wedge, and the Self-Service Portal — not a partner-dashboard-only story.
3.Mark stale any GTM material that collapses the company into one model or one channel.
4.Lock a short list of destination pilots and the first genre pack.
5.Treat Core ~$129 as the pricing anchor for experiments; do not block launch on perfect price discovery.
6.Charter engineering for a 30-day sprint: HTTP MCP, portal spine, and about ten real pilot endpoints — not more strategy prose.
7. Stand up lightweight legal: tourism pilot data terms, business terms of service, and basic telemetry privacy. Full data-product legal can wait.
1.Keep this file as the single operating strategy.
2.Align NORTH_STAR and GTM docs when they still tell a thinner story.
3.Lock destination pilot shortlist and first genre pack.
4.Treat Core ~$129 as the pricing anchor for experiments.
5.Charter a 30-day engineering sprint around Priority 0 — not more strategy prose.
6.Write the first quality/decommissioning standard before scale.
7. Stand up lightweight legal for pilots, ToS, and telemetry privacy.
---
## 14. Closing
## 18. Closing
The version of this company that is worth building is the ambitious one: endpoint infrastructure, intermediate distribution, a trust layer AI systems learn to prefer, and eventually a service graph that compounds. The thin version — “a partner dashboard that spits out an MCP file” — is easier to write down and much easier for someone else to crush.
The company worth building is the platform: multi-tenant MCP, genre systems, ingestion, quality, intermediate upgrade path, and eventually a service graph. The Self-Service Portal is how ordinary businesses turn that platform on. Tourism boards are how we attach many endpoints at once. Trust and decommissioning are how we stay preferred by machines that only nameone or two winners.
Market conditions in 2026 support urgency without requiring panic. Consumers are using AI for local discovery. Recommendation is highly selective. Shopify, Yelp, Google, and Cal.com all prove that MCP is real — and each protects its own layer. The long tail of local services still lacks a neutral on-ramp.
Market conditions support urgency without requiring panic. Consumers are using AI for local discovery. Recommendation is highly selective. Large platforms are MCP-enabling *their* layers. The long tail of local services still lacks a neutral on-ramp.
Our job as a funded planning team is to freeze a clear strategy, realign the docs, and execute the portal plus tourism pilot path until that vacuum starts filling under our name.
Freeze strategy. Realign docs. Ship the platform. Activate with the portal. Scale through intermediates. Protect trust like it is the product — because for AI engines, it is.
---
## Research notes
Key external reference points used while drafting this strategy:
- BrightLocal local consumer research (2026) on AI use for business recommendations
- SOCi 2026 Local Visibility Index and related coverage on recommendation selectivity
- Shopify Storefront MCP and agentic commerce materials
- Yelp Fusion AI MCP (public repository and product pages)
- Google Maps grounding and Merchant MCP materials
- Cal.com MCP documentation for booking lifecycle tools
- Public discussion of AI local discovery and agentic commerce
Re-verify statistics before every external pitch. Prefer primary sources over secondary rewrites when the number matters.
Reference points used while forming and revising this strategy include BrightLocal consumer research on AI local recommendations, SOCi’s Local Visibility Index and related coverage, Shopify Storefront MCP and agentic commerce materials, Yelp’s MCP/data-for-agents direction, Google Maps/Merchant MCP materials, Cal.com MCP documentation, and public discussion of AI local discovery. Re-verify statistics before external pitches.
| **[CANONICAL_STRATEGY.md](./CANONICAL_STRATEGY.md)** | Final-draft operating strategy — team plans, builds, and sells against this |
## Companion product specs
- [Product overview](../product/overview.md)
- [Use cases](../product/use-cases/)
If another doc conflicts with the canonical strategy, update that doc or deliberately revise the strategy. Do not leave both live.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
VPS admin