# 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 How the work is paced for the owner

The current plan is clear on **control**: evidence, approval before publish, low-risk fixes, and access before changes. What it does not yet spell out is **how the engagement feels for the owner** over time.

That gap matters. Without it, the service can feel either too heavy (owner in every decision) or too vague (unclear when setup ends and what happens when something changes).

**Two phases**

**Phase A — Initial corrective work**  
Up front, you and the owner work from a structured correction plan: what is wrong, what should be true, what copy and profile choices are recommended, what photos or other decisions are needed, and in what order updates go live. This takes real owner attention. That is intentional. The foundation has to be right once so the ongoing work can stay light.

The plan does not yet define this as a formal deliverable. **Work item:** a Correction Plan template (findings, target state, owner decisions, access required, publish sequence, and a clear definition of “setup is done”).

**Phase B — Ongoing change management**  
After setup, most changes are seasonal or one-off: holiday hours, a temporary closure, a phone change, a service add or drop — anything that should update the business’s **public presence** (the listings and the matching facts on the website, where that is in scope).

The owner should not manage five platforms. They notify once. You handle the rest on the surfaces you manage, including putting normal hours back when a temporary change ends.

Ongoing work is **not** “edit often.” It is stewardship: update when reality changes, refresh where it builds confidence, and leave alone what should stay stable. Hours and services move when the business does. Description and empty posts should not be rewritten for activity’s sake — constant change can weaken confidence. The operating plan still needs a simple **by-element cadence** so the team does not treat every surface the same.

The plan acknowledges temporary hours in spirit but does not yet define intake, handoff, or speed. **Work items:** one primary way for the owner to notify you; what a complete notice includes (especially end dates); written turnaround expectations so a holiday change does not go live a day late; and a clear Phase B boundary (facts/hours/services only vs also posts, review replies, photo refresh).

**Who does what (after the shape is clear)**

| Who | Role |
|-----|------|
| **Owner** | Confirms true facts during setup. Approves the correction plan and material wording. Later: sends a short notice when something must change. Approves only when the change is more than a straightforward factual or temporary update. |
| **DOP** | Builds the correction plan with the owner. Monitors. Drafts and, with access, publishes on agreed surfaces. Restores temporary changes on the end date. Reports what was done. |

### 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 What still needs deciding in this section

Grouped so the open work is easy to act on:

**A. Scope**  
- Which platforms are in Version 1?  
- Does Phase B cover only facts, hours, services, and attributes — or also posts, review responses, and photo refresh?  
- Is website content consistency part of ongoing public presence, and how deep (visible text only vs structured data)?  
- Foursquare / Bing Places: light awareness in MVP, or deeper hygiene later?

**B. Phase A (setup)**  
- Correction Plan template: required fields and definition of “setup is done.”

**C. Phase B (ongoing)**  
- How the owner notifies you (one primary channel).  
- What a complete notice must include (especially end dates for temporary changes).  
- Turnaround targets: acknowledge → draft → execute → restore.  
- After setup, which changes can run without per-item approval when the notice is complete.  
- Simple edit policy by element (when to change, temporary vs permanent tools, when restraint is better).

**D. AI sampling**  
- Method, how often, and how it is described to the owner so it is not oversold.

Until A–C are decided, control is documented; owner-facing pacing and freshness rules are not.

---

## 3. Ongoing value and packaging

### The problem
Many of the biggest wins 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.

**What the owner should be paying for ongoing** is stewardship of public presence: accurate, consistent, and **appropriately fresh**. That includes knowing when *not* to touch something. Drift watching is part of it. SME judgment about cadence — update hours immediately, refresh photos when needed, leave the description alone unless the business has truly changed — is what makes a quiet month still worth the fee.

Honest packaging should also reflect the two-phase shape in §2.5: real attention during setup, light touch after.

### Decisions still needed
1. How the monthly offer is described so it rests on stewardship and appropriate freshness — not only “we watch for drift.”  
2. What a clean monthly report looks like when there is little to fix (stewardship summary, not an empty repair list).  
3. When a client should be project + light follow-up instead of full retainer.  
4. Short plain list: always included vs always separate (website monitoring remediation; posts/reviews/photos if those stay outside core Phase B; anything beyond low-risk listing fixes).

---

## What is left before process and code

The operating docs already give you control: evidence, approval before publish, low-risk fixes, and access before changes. This review sharpened the **offer and the gaps**: trusted-advisor tone, fundamentals that AI systems still need, two-phase owner pacing, and ongoing value as stewardship of public presence — not only “nothing broke.”

**What still has to be locked at the business level** (before you write detailed process or ship product code):

1. **Version 1 scope** — Which platforms; whether Phase B is facts/hours/services only or also posts, reviews, and photos; how deep website content consistency goes.  
2. **Phase A deliverable** — A Correction Plan template and a clear “setup is done” line.  
3. **Phase B operations** — How the owner notifies you; turnaround expectations; what can run without per-item approval after setup; a simple edit policy so freshness helps and over-editing does not hurt.  
4. **Packaging** — How the monthly offer is described and priced around stewardship; what is included vs always separate; when a client is project-only instead of retainer.  
5. **Website monitoring boundary** — Exact always/never checks and who fixes what when something fails.

Until those are decided, engineering and playbooks will guess at the product.

**Important constraint:** Version 1 is **human-heavy and automation-light**. Judgment, copy, approvals, and platform work still run through people. That protects quality and the trusted-advisor promise. It also **limits how fast you can scale** client count without more skilled capacity. Do not plan growth as if this were a self-serve software product; plan it as an expert service with tools underneath. Automation can expand later — it should not be assumed as the Version 1 delivery model.

**Suggested sequence:** Lock the five business items above → write the Correction Plan template and Phase B intake/SLA rules into the operating docs → only then invest in automation where it clearly removes load without removing judgment.

---

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