grokbot_ty
4900e0a369
Give Bing Places and Yelp real weight next to GBP/Apple, note Core 3 richness order, and treat aggregators as a fact-distribution layer for Presence — not a genre parent.
20 KiB
How local businesses get AI to recommend them
Branch: planning-selfserve-audit (from planning-rev2)
Status: Working draft from conversation on 2026-10-01; cluster cut revised after GBP mapping pressure test the same day
Related: BUSINESS_PLAN.md · conventions in CONVENTIONS.md
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.
What we are trying to do
The mission, stated plainly: help local business owners get AI to recommend them.
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.”
The problem we are solving
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.
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.
The product
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?”
The flow we are designing toward:
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).
We then give the owner two scores, in plain language:
Presence answers: are you on the map? Are you listed with the major providers, and do your categories line up consistently?
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.
How people will use it (channel reality, September 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.
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.
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.
How we label kinds of businesses
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.
There is no single industry-wide taxonomy that Apple, Google, Bing, Yelp, and the listing aggregators all use. Each keeps its own list (or feeds someone else’s).
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.
Google Business Profile has its own category IDs (often looking like gcid:…), available through Google’s Business Information API (categories.list, region US / language en). That official list is a flat catalog of roughly 4,050 leaves — not a hierarchy that matches our genre parents. Google does not publish a downloadable tree that says “these GCIDs belong under service-area trades.” A public September 2026 compilation of 4,053 US English GCID names (with third-party industry buckets used only for structure) is useful for research; those buckets are not Google’s official parents. We use GBP GCIDs as outbound presence-check maps and fix suggestions, not as our spine. In practice GBP is usually the richest owner-facing surface (categories, services, attributes, photos).
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. Owner-facing field labels are documented; partner API schemas are often gated. Mid richness versus GBP — good for place card truth, weaker 1:1 parity on things like GBP serviceItems.
Bing Places for Business is Microsoft’s local listing surface (feeds Bing / Microsoft local experiences). Categories use Bing’s own IDs (BPCategoryId + name); owners can attach multiple categories with one primary. The trusted-partner API is certificate-gated, not a public crawl API — field maps on this branch already treat Bing as the thinnest of a “Core 3” with GBP and Apple (docs/product/genre-packs/). Bing still matters for Presence: wrong or missing Bing categories are a real “are you on the map?” miss, especially where Copilot / Microsoft surfaces lean on Bing Places data. Do not pretend Bing’s category tree equals Google’s.
Yelp keeps its own hierarchy of category aliases (developer APIs expose the tree). Yelp is both a discovery surface consumers still use and a signal assistants and third parties often scrape or cite. Alias mismatch (e.g. cuisine or trade labels that do not line up with GBP) is a classic consistency failure. Yelp is not a map pin in the same way as GBP/Apple/Bing, but it belongs in outbound maps when we score “would an AI trust this entity’s type?”
Data aggregators / syndicators sit underneath many of those surfaces. Companies such as Data Axle (local listings / formerly Infogroup-class syndication), Localeze / TransUnion digital business profiles, Foursquare Places (place graph / POI metadata), and similar players push NAP and rich fields out to search engines, directories, navigation apps, and assistants. Owners often never touch them directly — a “listing management” vendor or the platform itself does. For our product that means: Presence is not only “did you claim GBP?” It can also be “does the aggregator-fed copy of you disagree with the claim you just made?” Aggregators are not a ninth genre parent; they are a distribution layer for facts. Which aggregators we check in v1 (if any) is still open — but ignoring them entirely would understate how local data actually spreads.
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, Bing, Yelp, and (where useful) aggregator category codes when we check presence or suggest fixes.
We should not treat any single platform or aggregator list as our internal source of truth. They drift and they disagree. Building those maps ourselves is normal; nobody publishes an official multi-way concordance. On this branch, genre-pack work already sketches a Core 3 field map (GBP richest → Apple mid → Bing thinnest); extend that pattern to Yelp aliases and aggregator feeds only where Presence scoring needs them.
This taxonomy approach is a hypothesis until we score real businesses and see where the maps break.
Why one audit checklist is not enough
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.
What actually splits the audits:
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.
We are proposing eight top-level clusters plus one cross-cutting flag as a starting cut — also a hypothesis until real audits teach us to merge or split. A GBP category pressure test (flat GCID catalog + third-party industry buckets for structure only) pushed three corrections: split bring-to-shop trades away from service-area trades; narrow beauty away from medical; demote hybrid from a parent to a flag.
Service-area trades (plumber, HVAC, cleaner, landscaper, pest control): the provider goes to the customer. 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. Do not put auto repair here.
Destination workshop (auto repair, tire shop, furniture repair, shoe repair, and similar bring-the-item-in trades): the customer brings the asset to a shop with a public address. Presence is storefront-like (real pin, hours, specialty categories); recommendability is trade-like (job match, make/model or specialty, reliability). GBP catalogs Automotive separately from Construction & Trades / Home & Garden — that split supports this parent.
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.
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 separate products.
Professional / office services (lawyer, accountant): less weight on “open right now,” more on specialty, credentials, and clear service language.
Beauty (salon, barber, day spa, nails — formerly the non-medical slice of “home and personal care”): booking path and services on the presence side; skill match, portfolio, and outcome-themed trust on recommendability. Dentist, medical spa, and other clinical work belong under healthcare, not here.
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. This stays a rubric parent even though GBP will not hand it to us as one bucket — lodging leaves (hotel, motel, B&B) group fairly cleanly; tourism activity scatters across Sports, Education, Arts, and related leaves. Our audits still need one trip-intent rubric.
Healthcare / regulated (only if we take them on — including dentist and medical spa): higher bar for accurate categories and careful claims. Veterinary is an open decision: in the GBP research dump, pets/vets sit in a separate Pets neighborhood (~59 leaves), not inside Health & Medical — decide whether vets ride with healthcare/regulated or get their own call if they are in scope.
Hybrid / multi-mode is not a ninth parent. It is a cross-cutting flag that can sit on any cluster (dine-in plus delivery on food service; showroom plus install on retail or destination workshop). Presence and recommendability apply the relevant mode slices; the query tells you which mode matters. Google encodes many of these as specific leaves (delivery restaurant, mobile caterer), not as a top-level grouping.
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. Destination workshop is the natural pack when the wedge is auto repair (as in the older UC-01 example).
How we build it (phases)
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 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.
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.
Phase 3 — Self-serve loop. Results, a fix list, optional re-check, no mandatory human. Success: most people finish alone.
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.
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.
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.
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.
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.
How demand arrives (acquisition, not taxonomy)
This section is about who brings owners to the tool, not about which genre parent an audit uses. Genre clusters (destination workshop, beauty, hybrid as a flag, and the rest) stay a product-rubric question. Demand is orthogonal.
On main, distribution is framed as the hard part of local SaaS (docs/gtm/channel-strategy.md, echoed in NORTH_STAR.md and Canonical Strategy §10). The primary one-to-many wedge there is tourism / destination intermediates — tourism boards, DMOs, and visitor bureaus: one board contract unlocks many member endpoints, often funded by lodging-tax or visitor-experience budgets, upgrading board sites from weak link lists into structured destination surfaces (UC-02). A parallel path is self-serve SMBs in high-intent verticals. Chambers of Commerce show up as a secondary one-to-many path (CoC-branded portals, member-benefit framing). Agencies and SEO consultants are a partner layer that implements and sells — not the product center. BBB (Better Business Bureau) does not appear anywhere on main in that research pass; do not invent it into this SoT.
Soft link only: a tourism-board wedge prefers shipping the hospitality / tourism pack; an intermediate still needs category routing across members, which uses taxonomy as wiring, not as the definition of our parents.
This doc’s product flow already assumes many owners start themselves (including from ads). Main’s board-and-partner motion can coexist with that, but “ads / self-start only,” “intermediate-first,” or “both” is a real decision — not something the genre list answers.
Decisions still open
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 (Core 3 GBP/Apple/Bing, plus Yelp and/or aggregators such as Data Axle / Localeze / Foursquare — or claim-only first); 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; what never goes to a human versus when escalation is allowed; whether veterinary rides with healthcare/regulated or gets its own call if in scope (GBP research dump: separate Pets bucket, ~59 leaves, not folded into Health & Medical); and whether v1 demand is ads/self-start only, intermediate-first (tourism boards / chambers / partners), or both.
What we are treating as hypotheses
Until we score real businesses, treat these as educated bets, not finished truth: that eight top-level clusters plus a hybrid flag is the right split (including destination workshop separate from service-area trades, and beauty separate from healthcare); that schema.org plus outbound maps to Google, Apple, Bing, Yelp, and selected aggregators is the right labeling spine — not any one platform’s leaf list as internal SoT; 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).
Nothing in this doc is locked until Ty says so. Amend this file when decisions land — do not start a second near-named document.