From 7f3e3a1d3162d1439d5737c9ac1325f8ab01867f Mon Sep 17 00:00:00 2001 From: Tony Balascio Date: Sun, 16 Aug 2026 21:32:49 +0000 Subject: [PATCH] =?UTF-8?q?onboarding:=20SOP=20v1.1=20=E2=80=94=20website?= =?UTF-8?q?=20scope=20line=20+=20monitoring=20cadence=20(DR-001/DR-002)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/operations/owner-onboarding-sop.md | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/docs/operations/owner-onboarding-sop.md b/docs/operations/owner-onboarding-sop.md index 1735b48..8bca1b9 100644 --- a/docs/operations/owner-onboarding-sop.md +++ b/docs/operations/owner-onboarding-sop.md @@ -1,5 +1,5 @@ # Owner Onboarding SOP — 15-Minute Authority Transfer -**Status:** Locked v1.0 · 2026-08-16 +**Status:** Locked v1.1 · 2026-08-16 (scope per DR-001, cadence per DR-002) **Applies to:** Every VeriPath client, after first audit delivery, before monitoring/remediation loop starts. **Operator:** VeriPath (Leonard or Tony). Owner is a participant, not a student — she does 2 things: confirms facts, grants access. @@ -59,15 +59,29 @@ We cannot do this for her — Apple gates it on identity. Keep it honest and fas UI labels in ABC drift occasionally — follow the flow, not the exact wording. If the claim fails or the listing isn't found: fallback = **Suggest an edit** from Apple Maps on her listing (Apple reviews it, takes days) → log as pending, loop runs read-only on Apple until it lands. +### 3c. Website — no access grant at onboarding (per DR-001) +We do NOT take website admin access during onboarding. +- If we already hold project access (Phoenix: Lovable): fix the JSON-LD once as a one-time intervention, log it in the change log. Say so out loud: "We've fixed the hours markup on the site. That was a one-time fix — we don't control the site, and we're not pretending we do." +- If we do not hold access: hand the fix back with the exact change needed, and mark the website surface advisory in all future reports. +Either way the owner hears the same scope line as the reports. + ## P4 — Operating agreement + close (12:00–15:00) Say, roughly: > "Here's where we are. The record we just locked is the source of truth. We check Google, Apple, Bing, and your website against it on a schedule. When something drifts, we fix it — Google directly, Apple through your listing, website through you or whoever runs it — and you get a short note saying what we found and what we did. You don't check anything. If you ever want out, you remove us from Google in one click and close Apple Business Connect. Nothing here is a trap door." +**Scope (say it verbatim):** +> "We keep the business listing surfaces correct — Google, Apple, and Bing. The website is advisory: we tell you and your developer exactly what to change. If you want us to own the site's structured data going forward, that's a separate conversation we'll have." + Then: - [ ] Hand her the **trust receipt** (file, emailed) — what was confirmed, what access was granted, how to revoke each. - [ ] State the first monitoring cycle date. - [ ] Close. No upsell, no tutorial. ---- +## Monitoring (default cadence — DR-002) +- Days 0–30 after onboarding: daily audits (aggregators/caches still settling). +- After day 30: weekly. +- After any change we make, or any unstable surface: daily until 2 consecutive clean runs. +- The owner receives the trust receipt / monthly summary only. **No per-drift alerts.** +- Implementation (cron wiring, instability trigger) is deferred until after the first live onboarding — policy is locked, mechanism is not built yet. ## Update Protocol — canonical record (after P2) For every owner-confirmed field: @@ -101,7 +115,7 @@ Any incomplete outcome **must** appear in `gaps`. No silent partial access. - **She is not the GBP owner** → stop 3a. Note in gaps. Either the real owner does 3a, or loop runs read-only on Google until it happens. Never work around ownership. - **Apple verification pending (postcard)** → log in gaps; set hours as soon as claimed; loop read-only on Apple meanwhile. - **Hours corrected in P2** → canonical updated first; Apple step uses corrected values (P2→P3 order is load-bearing). -- **Website JSON-LD drift** → not an onboarding item. We don't take website admin by default; route the fix to whoever runs the site (for Phoenix: the redesign owner) and track as a finding. +- **Website JSON-LD drift** → 3c handles it. We don't take website admin by default; if we hold project access we fix it once (one-time intervention, logged), otherwise the fix is handed back and the surface stays advisory. - **Owner pushes back on access** → that's a trust conversation, not a checklist. Drop to read-only loop for the withheld surface, log the gap, and do not pressure. The loop still adds value on the surfaces she does grant. ## Pattern notes (for the next client) @@ -109,5 +123,5 @@ Everything client-specific is a placeholder: `{business}`, `{client_id}`, `{veri ## Appendix — Phoenix Salon + Spa (first run) - Canonical values to read back: Mon–Sat **9 AM–6 PM**, Sun **closed**; phone (530) 350-9197; 3460 Robin Ln, Ste 4, Cameron Park, CA 95682; category: beauty salon/spa. -- Known drift to fix in the loop after onboarding: Apple Maps shows 10 AM–6 PM all 7 days incl. Sunday (owner sets correct hours during 3b); website JSON-LD closes at 7 PM Mon–Fri, 5 PM Sat/Sun, open Sunday (route to site owner). +- Known drift to fix in the loop after onboarding: Apple Maps shows 10 AM–6 PM all 7 days incl. Sunday (owner sets correct hours during 3b); website JSON-LD closes at 7 PM Mon–Fri, 5 PM Sat/Sun, open Sunday (3c: one-time Lovable fix, logged). - GBP already clean per 2026-08-16 audit — 3a is grant-only, no data fix.