veripath/docs/DOP-BusinessReview_ty_grok_Aug062026.md

# Digital Operations Partner — Reality Check
### What still needs to be decided before this is a clean, sellable service

**Who this is for:** You — deciding whether the service is ready to sell and deliver without surprises.  
**Date:** August 6, 2026  
**Status:** Work in progress

---

## The big picture

You have a clear problem worth solving: local businesses quietly lose customers because their digital path is broken or incomplete, and they never find out.

The tone of the whole partnership is **trusted advisor**. Success depends on that. Owners should feel they are working with someone who understands these platforms at a professional level — not a junior clerk who only copies fields from one screen to another.

### What “trusted advisor” means here

AI chatbots are built to give **helpful** answers. Helpful requires public information that is:

- **Trustworthy** — accurate, not conflicting across sources  
- **Consistent** — the same identity, hours, and services wherever they appear  
- **Discoverable** — present and clear in the places people and systems look  

That is not a new AI rule. It is the same foundation that made local discovery work in 2017. In 2027 it does not get replaced; it gets **amplified**. When AI is the interface, weak or conflicting public facts hurt harder. Strong, consistent, trustworthy facts become more valuable, not less.

AI assistants are also a **moving target**. You cannot lock in a permanent “optimize for one chatbot” playbook. What *is* stable: every major system still builds discovery and recommendations on top of the same fundamentals that make human discovery possible. Own those fundamentals. Stay ready as the assistants stabilize.

**One-line value prop:**  
> We keep your business’s public information trustworthy, consistent, and discoverable — the same foundation that has always driven local success, and the one AI systems need to treat you as a helpful answer.

### How the top 3 chatbots triage local answers (mid-2026)

By market share the top three generative chatbots are **ChatGPT**, **Gemini**, and **Claude**. (Siri / Apple Intelligence matters for Apple-device local discovery via Apple Business Connect, but it is not a top-3 chatbot.)

| Assistant | How local answers tend to be built | Highest-leverage public signals |
|-----------|-------------------------------------|----------------------------------|
| **Gemini** | Heavy use of Google’s local graph | **Google Business Profile**, Maps/Places, reviews, categories, hours |
| **ChatGPT** | Bing web index + partner place data + public web | **Foursquare** places data, **Bing**-visible consistency, **business website**, directory NAP alignment (not a primary GBP pipe) |
| **Claude** | Tools/APIs + web; often Google Places when looking up locals | Google Places/Maps-aligned data, clear website, consistent public facts |

**MVP implication:** Own the fundamentals hard — GBP craft, website facts, NAP/hours consistency, temporary-hours discipline. That serves all three. ChatGPT specifically requires not ignoring aggregators (including Foursquare) and the website. Apple Business Connect is important for Siri/Maps users but is post-MVP relative to chatbot top-3 optimization unless your market is heavily Apple-primary.

**MVP investment focus:** GBP integrity + exposure craft · website content consistency · cross-directory NAP awareness · temporary-hours process · light AI diagnostics on ChatGPT + Gemini.  
**Post-MVP:** Deeper Foursquare/Bing Places/citation hygiene · Apple Business Connect · richer site FAQ/structure · tighter sample→fix loops.

Until the operating line is sharp (what you check, fix, only recommend, or never touch), engagements risk confusion. The sections below are the open decisions.

---

## 1. Website monitoring (standalone)

This is operational observation of the **website as a system** — not the same job as keeping website *content* consistent with listings (that sits under section 2).

### The problem
“We make sure customers can reach you” is vague. Checking that a booking link loads is one thing. Testing a full booking or watching server logs is another — and that becomes a different product.

### Practical Version 1
Visible, explainable checks only:

- Main booking/contact link resolves (page loads, no obvious error)
- Expected form, button, or booking widget is still present
- Primary “call us” / “book now” CTA present and pointed correctly
- Light technical health signals (e.g. robots.txt, sitemap.xml, canonicals, accidental noindex) if included in the standard checklist

**Not in Version 1:** end-to-end form/booking completion testing, server-log monitoring, full uptime/performance product.

### Decisions still needed
1. Exact always-checked / never-checked list in owner language  
2. Whether table-stakes indexability items are standard checks  
3. Remediation: DOP fixes (with access), owner fixes from guidance, or separate quote  
4. Evidence standard so reports do not over-claim  

**Until these are decided, website monitoring is not engagement-ready.**

---

## 2. Listings and public presence

One operating area: the public facts about the business across platforms **and** on the website as a content surface — plus how those facts show up when customers ask AI assistants.

### 2.1 Stable vs temporary facts

**Stable facts** (set once, then watch for drift): name, address, phone, website URL, core weekly hours, main categories.

**Temporary / variant facts** (need a real process): holiday hours, special hours, temporary closure, reopening date, seasonal hours. Conflicting “open” vs “closed” across surfaces is exactly the quiet failure this service prevents.

### 2.2 Process for temporary changes

1. Owner notifies once (text, email, or short form) — not five platforms.  
2. DOP updates in-scope surfaces (and flags website hours if published); records end date.  
3. Restore on end date — remove temporary notice, restore normal hours.  
4. Report what changed, where, when, and when it reverses.  

Without access, prepare exact changes for the owner — or obtain access first.

### 2.3 Exposure craft (trusted advisor, not field clerk)

Integrity is the floor. **Exposure craft** is the advisor layer: category strategy, guideline-safe description, useful attributes, service lists that match customer language, profile completeness, temporary hours handled so they help rather than confuse. Knowledge must stay current; platforms change.

**In scope (V1 direction, with access and approval):** clear listing improvements on agreed platforms — categories, description, attributes, services, hours including temporary, core completeness.  
**Out of scope or separate:** ongoing social posts, ads, full brand rewrite, photography, broad content marketing.

Competitive context (what nearby businesses claim on their profiles) may **inform** drafts — light, local, evidence-based. It is an input, not a standalone competitive-intelligence product in V1.

### 2.4 Website content consistency (under public presence)

The website is another surface for the same public facts. Name, address, phone, hours, and what the business does should match the listings story in normal text (and in structured form where practical).

This is **not** website monitoring (section 1). It is consistency of content with the rest of public presence. Especially important for ChatGPT-class systems that lean on the open web.

### 2.5 Who does what — and how the work is paced

The goal is **not** to turn the owner into a project manager. Up front there is a real joint effort to get the foundation right. After that, the owner’s job should be light: tell us when something changes, approve time-sensitive items when needed, and otherwise stay out of the weeds.

**Up front (heavier, shared)**  
We work together to establish the correct public facts, categories, description, and services — and to put access and approval paths in place. This is the correction plan. It takes owner attention once so the ongoing service can stay low-friction.

**Ongoing (light for the owner)**  
Most changes are seasonal or ad-hoc (holiday hours, temporary closure, a phone change, a service you add). The owner notifies once through a simple channel. DOP prepares and, with access and any required approval, executes across in-scope surfaces — including restore on the end date for temporary items.

| Who | Day-to-day role |
|-----|------------------|
| **Owner** | Confirms true facts at setup. Sends a short notice when hours or core details change. Approves listing copy or material changes when asked (especially time-sensitive ones). Grants platform access so DOP can execute. |
| **DOP** | Builds the initial correction plan with the owner. Monitors. Drafts fixes and listing improvements. Executes on in-scope platforms after access and approval. Restores temporary changes on schedule. Reports what was done. |

**Change process (low impact on the owner)**  
1. Owner sends one notice (or DOP flags something found in monitoring).  
2. DOP drafts the change (and copy if needed).  
3. Owner approves when the change is more than a simple factual correction — or when timing is critical.  
4. DOP publishes on in-scope platforms and confirms.  
5. For temporary items: end date is recorded and restore is scheduled without another owner chase if the original notice included the return date.

**Turnaround expectations (must be set in writing)**  
Time-sensitive work fails if it lands a day late (e.g. July 4 hours going live on July 3). Version 1 needs clear targets, for example:

| Step | Target direction (to lock) |
|------|----------------------------|
| Acknowledge owner notice | Same business day |
| Draft correction / copy for approval | Within 1 business day of notice (faster for known holidays when notice is early) |
| Owner approval window | Agreed response time so DOP is not blocked (e.g. 1 business day; escalate if silent on urgent items) |
| Execute after approval (or on pure factual fix with standing authority) | Same business day when possible; next business day maximum for standard items |
| Scheduled temporary restore | On the stated end date, without waiting for a second owner reminder |

Exact numbers are still a decision — but the service must publish them. A July 4 special that publishes on July 3 is a failed engagement, not a process footnote.

**Access** remains required before DOP makes changes; diagnosis and recommendations do not require it.

### 2.6 AI sampling (sub-bullet under public presence)

Light checks against ChatGPT and Gemini (optional Claude): a few realistic local/need queries to see whether the business appears and is described correctly.

**Diagnostic only** — soft evidence, not proof of a lost customer, not a ranking claim. Method, frequency, and owner-facing language still need to be fixed so it is not oversold.

### 2.7 Decisions still needed
1. Platforms in scope for V1 (integrity + temporary hours)  
2. Temporary-change handling as standard retainer work? (Recommendation: yes)  
3. Notification method  
4. End-date restore as hard rule  
5. Confirm ownership model above (up-front joint plan → light ongoing; draft / approve / execute)  
6. **Lock turnaround targets** for acknowledge, draft, owner approval window, execute, and scheduled restore  
7. Standing authority: which pure factual fixes can DOP execute without per-item approval once access exists?  
8. Website content consistency: standard in public-presence work? How deep (visible text vs structured data)?  
9. AI sampling method, frequency, owner language  
10. Foursquare / Bing Places hygiene: MVP awareness vs post-MVP depth  

---

## 3. Ongoing value and packaging

### The problem
Many high-impact issues are closer to “fix once” than “watch forever.” A monthly report that only says “nothing broke” will not feel valuable — especially before the owner has seen a clear win.

Real ongoing angles: platforms and AI change under the business; temporary hours and reopenings; competitors’ public claims shift; small failures appear; you carry the monitoring burden; you keep public facts trustworthy, consistent, and discoverable for people and AI. The up-front joint lift (section 2.5) is part of selling that honestly: heavier at the start, light for the owner after.

### Decisions still needed
1. How the monthly service is described and priced so it does not rest only on drift watching  
2. What a clean monthly report looks like when there is little to fix  
3. When a client should be project + light follow-up instead of full retainer  
4. Short plain list: always included vs always separate (ties to website monitoring remediation and any work beyond low-risk listing fixes)  

---

## What has already been decided in this review

| Topic | Decision |
|-------|----------|
| Full booking/form completion testing | Not in Version 1 |
| Server-log monitoring | Not in Version 1 |
| Website **monitoring** | Standalone; surface path/technical checks only; language must match method |
| Website **content consistency** | Part of listings & public presence — same facts story, not monitoring |
| llms.txt | Optional; not required for Version 1 |
| Partnership tone | Trusted advisor |
| Core value prop | Trustworthy, consistent, discoverable public information — foundation for humans and for AI helpful answers |
| AI strategy | Fundamentals first; assistants are a moving target |
| Top 3 chatbots for MVP focus | ChatGPT, Gemini, Claude |
| Gemini / ChatGPT / Claude triage | GBP-heavy · Bing+Foursquare+web · Places/web |
| Siri / Apple | Local-data surface via Apple Business Connect — not top-3 chatbot |
| Listing work | Integrity + exposure craft |
| Temporary hours | Notify once → update in-scope → restore on end date |
| Ownership model (direction) | Up-front joint correction plan; ongoing light for owner; DOP drafts and executes with access; turnaround targets required so time-sensitive changes do not miss the window |
| Competitive intel | Light input to drafts; not a V1 product |
| AI sampling | Sub-bullet under public presence; diagnostic only |
| MVP focus | GBP craft, website content consistency, NAP consistency, temporary-hours discipline, light AI diagnostics |
| Post-MVP | Deeper aggregators, Apple Business Connect, richer site structure/FAQs, tighter AI loops |

---

## Suggested next step

Lock the open decisions under **§1** (website monitoring checklist and remediation) and **§2** (platforms, temporary process, ownership confirmation, **turnaround targets**, website content depth, AI sampling method), then finish **§3** packaging so included vs separate is unambiguous.

---

*This is a working document, not a final plan. It exists to drive decisions, not to replace the operating manuals.*