From 1a912c96fc60f6e0e95ee84624d9b9acbaa02dc9 Mon Sep 17 00:00:00 2001 From: grokbot_ty Date: Thu, 1 Oct 2026 09:45:40 -0700 Subject: [PATCH] Rewrite self-serve concept doc in plain prose. Explain specialized terms inline, drop machine outline tone, keep mission through hypotheses in one SoT file. --- docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md | 255 +++++------------- 1 file changed, 67 insertions(+), 188 deletions(-) diff --git a/docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md b/docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md index aee5684..b6c0df5 100644 --- a/docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md +++ b/docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md @@ -1,260 +1,139 @@ -# Self-serve AI discoverability — concept +# How local businesses get AI to recommend them **Branch:** `planning-selfserve-audit` (from `planning-rev2`) -**Status:** Working draft — conversation checkpoint 2026-10-01 -**Role:** Single source of truth for the self-serve AI discoverability wedge (concept + phased plan) -**Related:** [`BUSINESS_PLAN.md`](./BUSINESS_PLAN.md) on `planning-rev2` lineage +**Status:** Working draft from conversation on 2026-10-01 +**Related:** [`BUSINESS_PLAN.md`](./BUSINESS_PLAN.md) · conventions in [`CONVENTIONS.md`](./CONVENTIONS.md) -This doc captures **ideas, concepts, and strategic direction** turned into actionable phases for the self-serve “Am I discoverable by AI?” wedge. It is not an inventory of old-repo artifacts. Do not spawn a parallel PLAN.md — revise this file in place. +This is the single working doc for the self-serve “Am I discoverable by AI?” idea — both the *why* and the phased *how*. Revise this file in place. Do not add a sibling PLAN or CONCEPT file for the same subject. --- -## 1. Mission +## What we are trying to do -**How local business owners get AI to recommend them.** +The mission, stated plainly: **help local business owners get AI to recommend them.** -Owner-to-AI is the center of gravity. Proof (audits, scores, before/after) is a **selling point**, not the mission. The mission is recommendation in the agent era — not becoming another consumer destination, and not selling a protocol. +That puts the owner talking to AI (or using a tool that talks to AI on their behalf) at the center. Scores, audits, and before/after proof are useful for selling and teaching — they are not the mission itself. We are not building another website where consumers browse listings, not rebuilding booking or shop software, and not defining ourselves as “an MCP company.” --- -## 2. Problem frame +## The problem we are solving -| Layer | Stance | -|-------|--------| -| **Spine** | Agent-era local SMB discoverability | -| **Pipes** | MCP (or other transports) are implementation choices, **not** the product | -| **Northstar (not v1)** | An industry-wide graph others can use | -| **Not** | A consumer browse site; rebuilding Calendly/Shopify; “we are an MCP company” | +Local businesses are entering an era where people ask assistants — ChatGPT, Claude, Gemini, Perplexity, and whatever comes next — for a plumber, a place to eat, or a surf rental near them. If those assistants cannot find or trust a business’s facts, the business simply does not get recommended. -v1 earns structured, consented business truth by helping owners see and fix how AI sees them. The graph comes **after** that truth is worth composing. +That **discoverability in the agent era** is the spine of the strategy. How assistants connect to tools and data (for example through MCP, the Model Context Protocol — a technical way for an AI app to call outside tools) is just plumbing. We may use MCP later, or other approaches, or a mix. The pipe is not the product. + +Longer term, the Northstar — the destination we aim at but do not build first — is an **industry graph**: a shared, structured map of local businesses that many products and assistants could use. That is not version one. Version one earns the right to that graph by helping owners see how AI sees them today and fix what is broken, with their consent. --- -## 3. Product +## The product -A **self-service** experience — standalone web portal and/or inside a business’s own chatbot — where an owner asks: +A self-service experience — first as an interactive website, and later possibly inside a business’s own chatbot using the same engine — where an owner can ask: **“Is my business discoverable by AI?”** -> “Is my business discoverable by AI?” +The flow we are designing toward: -### Target flow +Someone who claims the business starts the check. We verify they are actually a stakeholder — for example by sending a six-digit code to an email already on file for that business — so random people cannot run deep audits on someone else’s shop. Once verified, we run a check that goes further than the old local-SEO habit of matching name, address, and phone (often called NAP) across directories. We also look at **categories** (what kind of business the listing says it is — plumber versus restaurant versus hotel) and **relevance** (whether those facts would help an assistant pick this business for a real customer question). -1. **Initiate** — Owner (or trusted helper / their AI) starts on an outcome promise, not plumbing. -2. **Stakeholder verify** — e.g. six-digit code to a known email on file. Unverified users do not get the deep audit. -3. **Deep audit** — Beyond NAP consistency across major providers into **categorical information** and **relevance**. -4. **Two scores** - - **Presence** — Are they on the map? (major providers + category consistency) - - **Recommendability** — If they are, would an AI engine likely recommend them for genre-relevant queries? -5. **Self-serve next steps** — Plain-language findings + ranked DIY fixes; optional re-check. Human expert path is an escape hatch, not the default. +We then give the owner two scores, in plain language: -### Positioning +**Presence** answers: are you on the map? Are you listed with the major providers, and do your categories line up consistently? -As much business-owner-to-AI as possible. Human-in-the-loop resources exist but **will not scale** — design minimizes human dependency. Advertising and similar demand programs drive SMBs to **self-initiated** audits. +**Recommendability** answers: if you are on the map, would an AI be likely to recommend you when someone asks about something in your genre? + +Finally we show what to fix, ranked so the owner can do it themselves, and let them re-check later. A human expert can be an escape hatch. It must not be required for the product to work — humans will not scale to every small business. + +Demand should mostly come from owners who start themselves (including from ads that send them to the tool), not from sales calls for every audit. --- -## 4. Channel reality (as of September 2026) +## How people will use it (channel reality, September 2026) -Research snapshot (late Sep / early Oct 2026): +We checked how major consumer chatbots behave with MCP as of late September / early October 2026. None of the big ones will automatically “handshake” with a random small business’s MCP server if nobody configured a connector. ChatGPT, Claude, consumer Gemini, Perplexity, Microsoft 365 Copilot, and similar products either need someone to add a connector or they only suggest connectors that are already in a curated directory. That is setup work — not something a typical shop owner gets for free by putting an MCP URL on the internet. -- **No** major consumer chatbot (ChatGPT, Claude, Gemini consumer, Perplexity, M365 Copilot, etc.) will **auto MCP-handshake** with a random SMB’s server with **zero** owner/developer configuration. -- MCP support that exists is **connector/config** (and sometimes curated directories / suggested connectors for listed partners) — not silent discovery of every business MCP as an inference engine. -- Those same assistants **still read normal web pages** as web content. That is **not** an MCP session. +Those same assistants can still open and read a normal web page as text. Reading a page is not the same as speaking MCP to a server. -### Product implication - -| Priority | Channel | -|----------|---------| -| **Highest now** | Interactive **web app** (owner completes audit in-browser) | -| Optional parallel | Embed the **same engine** in the business’s chatbot shell | -| **Revisit in ~3 months** | MCP / remote connectors as a distribution pipe — not the v1 product | - -Do not block the wedge on MCP adoption in consumer chat UIs. +So for version one, the highest priority is an **interactive web app** the owner completes in a browser. Embedding the same engine in a business chatbot can come later. We should revisit MCP as a distribution pipe in about three months — not block the product on it now. --- -## 5. Taxonomy stance +## How we label kinds of businesses -There is **no** single canonical “SMB genre” taxonomy that Apple, Google, and Yelp snap to for discovery. +A **taxonomy** here means the set of categories used to say what kind of business something is — plumber versus restaurant versus hotel — so listings, maps, and assistants know what queries it belongs to. -| System | Role | -|--------|------| -| **NAICS** | Official US statistical / production classification ([census.gov/naics](https://www.census.gov/naics/)) — useful for B2B/industry codes, **not** how people search “plumber near me” | -| **SIC** | Legacy; NAICS replaced it for federal stats | -| **Google Business Profile** | Own category IDs (`gcid:…`); listable via Business Information API | -| **Apple Business Connect / Maps** | Own primary + additional categories; data-spec historically published as categories CSV (docs moving under Apple Business rebrand) | -| **Yelp** | Own hierarchical aliases; public via Fusion categories API | -| **schema.org LocalBusiness** | Open, web-native type hierarchy — best **spine** for an AI-era product that also publishes structured web truth | +There is no single industry-wide taxonomy that Apple, Google, and Yelp all use. Each platform keeps its own list. -**No official Apple ↔ Google ↔ Yelp concordance** exists. Multi-platform presence products build their own maps. +**NAICS** (North American Industry Classification System) is the U.S. government’s statistical system for classifying businesses by what they produce. It is good for reports and some B2B software. It is not how someone searches “plumber near me” on a map. **SIC** is the older system NAICS replaced for federal stats. -### Recommendation (locked as direction, details iterative) +**Google Business Profile** has its own category IDs (often looking like `gcid:…`), available through Google’s business APIs. **Apple Maps / Business Connect** has its own primary category (one main label) plus optional extras; the public docs have been shifting as Apple folds Connect into a broader “Apple Business” offering. **Yelp** has its own tree of category aliases, published through Yelp’s developer APIs. -- **Internal spine:** thin product genre layer in **owner language**, keyed to **schema.org LocalBusiness** where it fits -- **Optional:** NAICS for statistical / B2B -- **Outbound maps:** GBP categories, Apple categories, Yelp aliases — for presence pulls and fix guidance -- **Do not** adopt Apple, Google, or Yelp as the internal source of truth +**schema.org’s LocalBusiness** types are an open vocabulary used widely on the web for structured data (the markup that helps search engines understand a page). That is the best spine for an AI-era product that also wants to publish clear web facts: owner-friendly genres inside our product, keyed to schema.org where they fit, optional NAICS when a statistical code helps, and **outbound maps** — translation tables — from our genres to Google, Apple, and Yelp categories when we check presence or suggest fixes. -**Hypothesis pending real audit data:** spine + maps quality will improve as we score real businesses; revise mappings from evidence, not from guessing. +We should not treat Apple’s, Google’s, or Yelp’s lists as our internal source of truth. They drift and they disagree. Building those maps ourselves is normal; nobody publishes an official three-way concordance. + +This taxonomy approach is a **hypothesis** until we score real businesses and see where the maps break. --- -## 6. Genre clusters (audit complexity) +## Why one audit checklist is not enough -**One dual scoreboard, cluster-variant rubrics.** A plumber running from a truck and a surfboard rental for tourists are different products of “on the map” and “would AI recommend.” +A plumber who works out of a truck and a surfboard rental that serves tourists are both “local businesses,” but “are you on the map?” and “would AI recommend you?” mean different things for each. The product can keep one shared scoreboard — Presence and Recommendability — and change the **rubric** (what evidence counts and how heavily) by **genre cluster**. -### Dimensions that split audits +What actually splits the audits: -- **Where value is delivered** — customer comes to you vs you go to them vs hybrid vs mobile/seasonal spot -- **What “place” means** — fixed storefront / hidden service-area address / destination landmark / multi-location -- **Decision data** — menu, services list, inventory, booking, hours-open-now, price band, amenities -- **Demand shape** — emergency, same-day convenience, planned occasion, tourist/trip, B2B research -- **Trust signals** — review volume/velocity, photos, licenses, brand vs indie -- **Seasonality / hours rigidity** -- **B2C vs B2B** — who the AI is helping choose +Where the work happens (customer comes to you, you go to them, both, or a moving spot). What “place” means (a storefront with a public address, a service-area business that hides its address, a tourist landmark, or many locations). What decision data matters (menu, service list, booking, hours open right now, amenities). What kind of demand it is (emergency, same-day convenience, a planned night out, a trip, or B2B research). How trust shows up (reviews, photos, licenses). Seasonality. And whether the AI is helping a consumer or a business buyer. -### Proposed clusters +We are proposing eight clusters as a starting cut — also a hypothesis until real audits teach us to merge or split: -| # | Cluster | Presence emphasizes | Recommendability emphasizes | -|---|---------|---------------------|----------------------------| -| 1 | **Service-area trades** (plumber, HVAC, cleaner) | SAB vs fake storefront; service areas; category/services; no walk-in theater | Job-type relevance; coverage of searcher’s area; reliability/license themes | -| 2 | **Storefront retail** | Address/signage/hours; category; attributes; multi-location | Assortment fit; open-now; real stock photos; neighborhood fit | -| 3 | **Food service** (restaurants, cafés, bars, trucks) | Cuisine/format category (not generic Restaurant); hours; menu freshness; dine-in/takeout/delivery; truck location/events | Cuisine + occasion intent; price/ambiance; dietary clarity; review recency; open-now | -| 4 | **Professional / office** | Category depth; service pages; citations; weaker “open now” weight | Specialty match; credentials; authority language | -| 5 | **Home & personal care** (salon, dentist, medspa) | Booking path; services; hours; category | Skill match; booking friction; outcome-themed reviews | -| 6 | **Hospitality & tourism** (hotel, surf rental, tour) | Lodging/activity category; amenities; destination geo; seasonal hours; OTA vs owned facts | Trip-intent fit; amenity truth; landmark relevance; seasonal availability | -| 7 | **Healthcare / regulated** (if in scope) | Category + attribute accuracy; hours; locations | Condition/specialty match; acceptance; careful claims | -| 8 | **Hybrid / multi-mode** | Storefront **and** service-area rules both correct | Mode implied by query; flag mismatches | +**Service-area trades** (plumber, HVAC, cleaner): presence cares about looking like a real service-area listing rather than a fake storefront, having coherent service areas and categories; recommendability cares about matching the job type and the customer’s area, plus reliability signals. -**Restaurant sub-genres** (fine dining vs QSR vs food truck, cuisine types) are **parameters inside food service**, not separate products. +**Storefront retail:** presence cares about address, hours, and category truth; recommendability cares about whether the assortment fits the ask and whether the shop is actually open. -### v1 pack order +**Food service** (restaurants, cafés, bars, food trucks): presence cares about specific cuisine or format categories (not a vague “Restaurant”), hours, and a current menu; trucks also need “where are you today.” Recommendability cares about occasion (date night versus quick lunch), price and vibe signals, dietary clarity, and fresh reviews. Fine dining, quick service, and trucks are **parameters inside this cluster**, not eight separate products. -Start with **two** cluster packs that prove the split: +**Professional / office services** (lawyer, accountant): less weight on “open right now,” more on specialty, credentials, and clear service language. -1. Service-area trades -2. Food service +**Home and personal care** (salon, dentist, medspa): booking path and services on the presence side; skill match and outcome-themed trust on recommendability. -(If the commercial wedge is tourist SMBs, hospitality/tourism may swap with food service as the second pack.) +**Hospitality and tourism** (hotel, surf rental, tour): destination and amenity truth, seasonal hours, and conflicts between the business’s own facts and big travel sites; recommendability is trip-intent fit (“family,” “near the break,” pet-friendly) and seasonal availability. -**Hypothesis pending real audit data:** these eight clusters and their weight packs will be validated or merged once we score live businesses; do not treat the table as final ontology. +**Healthcare / regulated** (only if we take them on): higher bar for accurate categories and careful claims. + +**Hybrid** (dine-in plus delivery, showroom plus install): both storefront and service-area rules have to be right; the query tells you which mode matters. + +For version one, start with **two** cluster packs that prove the split matters — service-area trades and food service. If the commercial wedge is tourist businesses, hospitality can swap in for food service as the second pack. --- -## 7. Phases (0–5) +## How we build it (phases) -| Phase | Focus | Success | -|-------|--------|---------| -| **0** | Lock promise, wedge genre, shell (web first) | Promise in one breath without naming a pipe | -| **1** | Trust gate (claim + email code verify) | Verified only reach deep audit | -| **2** | Audit engine — Presence + Recommendability | Repeatable scores; owner understands why | -| **3** | Self-serve loop — findings, DIY fixes, recheck | Majority finish without human | -| **4** | Demand — ads to self-initiated audits | Funnel rates known | -| **5** | Toward industry graph | Only after consented structured truth is worth composing | +**Phase 0 — Lock the promise.** One sentence an owner gets without jargon. Who we speak to first. What “recommendable” means in plain words. Confirm the first shell is the web app. Success: we can say the promise in one breath without naming MCP or any other pipe. -### Phase 0 — Lock the promise +**Phase 1 — Trust gate.** Claim the business, verify the stakeholder (email code first), keep data light, consent clear, and abuse limited. Success: only verified people reach the deep audit. -- One-sentence value prop owners understand without jargon. -- First wedge genre (who we speak to first). -- Plain-language definition of “recommendable.” -- v1 shell decision: web first (see §4); chatbot embed optional later; one engine. +**Phase 2 — Audit engine.** This is the product: Presence and Recommendability with a thin, explainable rubric and cluster-specific weights — not a black box. Success: running the same business twice gives roughly the same scores, and the owner understands why. -**Success:** The promise can be said in one breath without naming a transport (MCP, etc.). +**Phase 3 — Self-serve loop.** Results, a fix list, optional re-check, no mandatory human. Success: most people finish alone. -### Phase 1 — Trust gate +**Phase 4 — Demand.** Light campaigns that send owners to start their own audit. Track start → verify → complete → recheck. Success: we know acquisition cost and completion rate well enough to improve. -- Claim-a-business + stakeholder verification (email code first; other signals later). -- Minimal PII, clear consent, rate limits / abuse controls. +**Phase 5 — Toward the graph.** Only after audits produce structured facts owners consented to share that are worth composing into something bigger. The graph stays the Northstar; it does not gate version one. -**Success:** Verified owners reach the audit; unverified cannot. +Ship in this order: promise and wedge, verify gate, presence score, recommendability score, results and fixes, recheck, then ads. Do not wait on the industry graph or on a single technical protocol. -### Phase 2 — Audit engine (the product) +Version one is succeeding when an owner can finish alone, sees two clear scores with a real explanation, gets fixes they can do themselves, can re-check, and ads can point at the tool without a sales call on every lead. -- **Presence score:** On the map across major providers + category consistency. -- **Recommendability score:** Likelihood an AI would surface them for genre-relevant queries. -- Start with a thin, explainable rubric — not a black box — with **cluster-variant weight packs** (§6). -- Outputs: plain-language findings + ranked owner-actionable fixes. - -**Success:** Same business twice ≈ same scores; owner understands why. - -### Phase 3 — Self-serve loop - -- Results page / chat readback, fix checklist, optional re-check. -- No mandatory human review. -- Optional “ask an expert” as escape hatch only. - -**Success:** Majority complete without human touch. - -### Phase 4 — Demand - -- Lightweight campaigns that send SMBs to the portal for a self-initiated audit. -- Funnel metrics: start → verify → complete → recheck. - -**Success:** Acquisition cost and completion rate are known; creative/genre can iterate. - -### Phase 5 — Toward the graph (later) - -- Only after audits produce structured, consented business truth worth composing. -- Graph remains Northstar; does not gate v1. - -### Build order (what ships first) - -1. Promise + wedge genre -2. Verify gate -3. Presence score -4. Recommendability score -5. Self-serve results / fixes -6. Recheck -7. Then ads / demand programs - -Do **not** wait on the industry graph or a single wire protocol. - -### v1 success bar - -- Owner can finish alone -- Two clear scores with explainable why -- Actionable DIY fixes -- Repeatable recheck -- Ads can point at it without a sales call - -### Workstreams (parallel once Phase 0 is clear) - -| Workstream | Owns | -|------------|------| -| Promise & wedge | Positioning, genre, “recommendable” language | -| Trust & verify | Claim flow, codes, consent, abuse | -| Presence engine | Provider coverage, NAP + category checks | -| Recommendability engine | Rubric, explainability, genre relevance | -| Experience shell | Web and/or chatbot UX on one engine | -| Growth | Campaigns, funnel metrics | -| Graph (later) | Composition of consented structured truth | +Once Phase 0 is clear, work can run in parallel streams: promise and wedge language; trust and verify; presence checks; recommendability rubric; the web (and later chat) shell; growth metrics; and only later, graph composition. --- -## 8. Open decisions +## Decisions still open -Still for Ty to lock: - -- First **v1 genre / cluster pack** (trades vs food vs hospitality) -- **Shell:** web-only v1 vs web + chatbot embed -- Which **providers** feed Presence -- How **Recommendability** is measured without overclaiming (heuristics vs live assistant checks) -- Source of **email on file** for verify -- **Free vs paid** audit -- What **never** goes to a human; when escalation is allowed +Ty still needs to lock: which cluster pack we ship first; whether version one is web-only or also embeds in a chatbot; which providers feed the Presence score; how we measure Recommendability without overclaiming (simple heuristics versus live checks inside assistants); where the “email on file” for verification comes from; free versus paid; and what never goes to a human versus when escalation is allowed. --- -## Hypotheses (explicit) +## What we are treating as hypotheses -Mark as **hypotheses pending real audit data** — revise from scored businesses, not from debate alone: +Until we score real businesses, treat these as educated bets, not finished truth: that eight clusters is the right split; that schema.org plus maps to Google, Apple, and Yelp is the right labeling spine; that two version-one packs are enough to prove cluster-specific rubrics; and that a web app beats an MCP-first distribution story for owners in the near term (revisit in about three months). -1. Eight genre clusters are the right split (may merge/split). -2. schema.org LocalBusiness + outbound maps to GBP/Apple/Yelp is the right taxonomy spine. -3. Two v1 packs (service-area trades + food service) are enough to prove cluster-variant rubrics. -4. Interactive web app outperforms MCP-first distribution for SMB owners in the near term (~3 month revisit). - ---- - -## Capture note - -Drafted from strategy conversation 2026-10-01 (voice + chat). Former duplicate `SELF_SERVE_AI_DISCOVERABILITY_PLAN.md` was merged into this file and removed — keep a single SoT. Nothing is locked until Ty says so. +Nothing in this doc is locked until Ty says so. Amend this file when decisions land — do not start a second near-named document.