Revert: undo unauthorized ownership/SLA rewrite; restore prior discussion state of the doc

This commit is contained in:
Ty
2026-08-07 00:27:43 +00:00
parent f0a018e125
commit 21247c2774
+15 -43
View File
@@ -108,42 +108,16 @@ The website is another surface for the same public facts. Name, address, phone,
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
### 2.5 Responsibility (RACI) — one model for facts and wording
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 owners job should be light: tell us when something changes, approve time-sensitive items when needed, and otherwise stay out of the weeds.
| Role | Responsibility |
|------|----------------|
| **Owner** | Supplies true facts; notifies temporary changes; **approves** wording and material listing changes |
| **DOP** | Monitors; drafts recommendations and listing copy (informed by craft + light competitive context); **implements** on in-scope platforms when access is granted |
| **Access** | Prerequisite for implementation — not for diagnosis or recommendations |
**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.
Default for listing copy: **DOP drafts → owner approves → DOP implements (access required).**
Same access philosophy covers field corrections and temporary hours.
### 2.6 AI sampling (sub-bullet under public presence)
@@ -156,12 +130,10 @@ Light checks against ChatGPT and Gemini (optional Claude): a few realistic local
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
5. Confirm RACI default above (draft / approve / implement / access)
6. Website content consistency: standard in public-presence work? How deep (visible text vs structured data)?
7. AI sampling method, frequency, owner language
8. Foursquare / Bing Places hygiene: MVP awareness vs post-MVP depth
---
@@ -170,7 +142,7 @@ Light checks against ChatGPT and Gemini (optional Claude): a few realistic local
### 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.
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.
### Decisions still needed
1. How the monthly service is described and priced so it does not rest only on drift watching
@@ -197,7 +169,7 @@ Real ongoing angles: platforms and AI change under the business; temporary hours
| 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 |
| Content / facts RACI (direction) | Owner supplies facts & approves wording; DOP drafts & implements with access |
| 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 |
@@ -207,7 +179,7 @@ Real ongoing angles: platforms and AI change under the business; temporary hours
## 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.
Lock the open decisions under **§1** (website monitoring checklist and remediation) and **§2** (platforms, temporary process, RACI confirmation, website content depth, AI sampling method), then finish **§3** packaging so included vs separate is unambiguous.
---