# Digital Operations Partner A human-supervised, agent-assisted digital operations service for local service businesses. This project exists to prevent silent customer loss by making sure customers can find, trust, and engage a business, and that search engines and AI systems can find, understand, and accurately represent it — often before the business would notice something was wrong. This repository defines the business foundation, operating model, evidence standards, client lifecycle, Path to PoC sequencing, and tooling for a Digital Operations Partner service. --- ## Working Definition > We continuously prevent silent customer loss for local businesses by making sure customers can find, trust, and engage the business, and that search engines and AI systems can find, understand, and accurately represent it, often before the business would ever notice something was wrong. This is a working definition, not a final brand statement. For the full business requirements, see: `docs/business-model/business-requirements.md` --- ## Core Concepts ### Silent Customer Loss Silent Customer Loss is the umbrella term for customer acquisition problems that occur without the business owner clearly seeing the loss. It includes: - **Customer Path Leakage** — a customer has interest or intent, but digital friction prevents contact, booking, visiting, or engagement. - **Discovery Failure** — a potential customer never meaningfully encounters the business because customers, search engines, or AI systems do not find, understand, surface, or accurately represent it. ### Service Domains 1. **Customer Path Integrity** — customers can find, trust, contact, book, visit, or otherwise engage without preventable digital friction. 2. **AI Visibility Integrity / AEO** — search engines and AI systems can find, understand, and accurately represent the business. 3. **Local Competitive Awareness** — local market context via competitor visibility, positioning, review movement, and AI-answer comparison. ### Evidence Model - **Tier 1: Verified Evidence** — concrete, timestamped, observable, or instrument-backed findings. - **Tier 2: Indicative Evidence** — sampled, directional, probabilistic, or risk-based findings. Agents may propose classifications; humans approve final tiers before client-facing use in Version 1. ### Operating Rule > Agents may detect and draft. Humans approve before publish. --- ## Path to PoC (Governing Sequence) Master sequence: `docs/architecture/path-to-poc-sequencing.md` Layers (fixed order): 1. Account Intelligence (Data Inventory) 2. Threat Diagnosis (Threat Register) 3. Economics & Pricing Validation 4. Requirements 5. Workflows 6. Agent Build & Test 7. POC Delivery Client artifacts live under `docs/clients//`. --- ## Agent & Audit Tooling | Doc / Tool | Path | |------------|------| | Agent Charter | `docs/agents/agent-charter-v1.md` | | Audit Playbook | `docs/agents/audit-playbook-v1.md` | | Leonard GBP Execution Card | `docs/agents/leonard-gbp-execution-card.md` | | GBP Snapshot Intake (markdown) | `docs/templates/gbp-snapshot-intake.md` | | GBP Snapshot Form (HTML) | `tools/gbp-snapshot-form.html` | | Data Inventory template | `docs/templates/data-inventory-template.md` | | Threat Register template | `docs/templates/threat-register-template.md` | | Requirements template | `docs/templates/requirements-template.md` | | Workflows template | `docs/templates/workflows-template.md` | **Cold audit GBP workflow:** open `tools/gbp-snapshot-form.html` → fill → generate → paste to Leonard with the execution card instruction. --- ## Active Client Instances | Client | Status | Path | |--------|--------|------| | Overcome Fitness | Draft Benchmark (Layers 1–2 in progress; GBP still open) | `docs/clients/overcome-fitness/` | --- ## V1 Scope Exclusions Out of scope for V1 unless separately quoted: - Social media production - Paid advertising - Website redesign - Branding projects - Content marketing - Full SEO campaigns - CRM / email marketing --- ## Go-To-Market Motion Proof-of-concept first. Demonstrate value through focused assessment, evidence-backed findings, a low-risk PoC fix when appropriate, and a before/after report. Retainer follows demonstrated value. --- ## Repository Structure ``` docs/ vision/ architecture/ # Path to PoC, economics guide, principles business-model/ use-cases/ templates/ # Layer templates + GBP intake agents/ # Charter, playbook, execution cards clients/ # Per-client instances workflows/ roadmap/ research/ specifications/ implementation/ tools/ # Operational forms (GBP snapshot HTML, etc.) ``` --- ## Current Phase **Phase: Path-to-PoC execution + first client benchmark** Resolved foundations: - Mission and working definition - Evidence model and operating rule - Client lifecycle and V1 exclusions - Path to PoC sequencing (7 layers) - Economics & pricing execution guide - Audit playbook + Layer templates - GBP cold-audit intake form + Leonard execution card - First non-Phoenix client instance (Overcome Fitness) as Draft Benchmark Open work: - GBP snapshot for Overcome Fitness (human form pass) before Layer 1/2 lock - Economics validation with real client numbers - Leonard scored runs against the playbook - Pricing validation and delivery packaging --- ## Philosophy Users → Problems → Requirements → Workflows → Agents → Tools No automation runs until the business is understood.