Add Employee Onboarding Manual v1 — full workflow, rules, tools, day-one procedures
This commit is contained in:
@@ -0,0 +1,352 @@
|
||||
# Employee Onboarding Manual — Digital Operations Partner (v1)
|
||||
|
||||
**Audience:** Any employee, contractor, or operator joining the company
|
||||
**Purpose:** Give you everything you need to work inside DOP without guessing
|
||||
**Source of truth:** The Gitea repository `Tony_tech/digital-operations-partner`
|
||||
**Status:** Active operating guide (reflects system as of 2026-08-02)
|
||||
|
||||
---
|
||||
|
||||
## 1. What this company does
|
||||
|
||||
### 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 owner would notice something was wrong.
|
||||
|
||||
### What Silent Customer Loss means
|
||||
Problems that cost the business customers **without the owner clearly seeing the loss**:
|
||||
|
||||
- **Customer Path Leakage** — interest exists, but digital friction blocks contact, booking, visit, or engagement (broken links, no booking button, wrong phone, dead CTAs).
|
||||
- **Discovery Failure** — the business is hard to find or is misrepresented in search, maps, or AI answers.
|
||||
|
||||
### Three service domains
|
||||
1. **Customer Path Integrity** — can a real person complete the path from interest → contact/book/visit?
|
||||
2. **AI Visibility Integrity / AEO** — can search engines and AI systems find and accurately represent the business?
|
||||
3. **Local Competitive Awareness** — what is happening in the local competitive set (visibility, reviews, positioning)?
|
||||
|
||||
### What we are *not* (V1)
|
||||
Do **not** sell or deliver as core offering unless separately quoted:
|
||||
- Social media content production
|
||||
- Paid advertising management
|
||||
- Website redesign
|
||||
- Branding projects
|
||||
- Content marketing campaigns
|
||||
- Full SEO campaigns
|
||||
- CRM / email marketing
|
||||
|
||||
We are a **digital operations oversight** business, not a general marketing agency.
|
||||
|
||||
---
|
||||
|
||||
## 2. Non-negotiable operating rules
|
||||
|
||||
Memorize these. They govern every task.
|
||||
|
||||
1. **Agents detect and draft. Humans approve before publish.**
|
||||
Nothing client-facing goes live without a human sign-off in Version 1.
|
||||
|
||||
2. **Evidence Model only**
|
||||
- **Tier 1 (Verified):** concrete, timestamped, observable, or instrument-backed.
|
||||
- **Tier 2 (Indicative):** sampled, directional, probabilistic, or risk-based.
|
||||
Ambiguous findings default to Tier 2. Agents propose; humans approve final tiers.
|
||||
|
||||
3. **No invented numbers, threats, or client facts.**
|
||||
If you did not observe it or the owner did not provide it, do not write it as fact.
|
||||
|
||||
4. **Fixed order of work**
|
||||
Users → Problems → Requirements → Workflows → Agents → Tools
|
||||
Do not design agents or tools before requirements and workflows exist.
|
||||
|
||||
5. **Draft → Human Review → Locked**
|
||||
Every lasting artifact has a status. Never treat a Draft as Locked.
|
||||
|
||||
6. **Prefer the stricter, more evidence-bound position** when uncertain.
|
||||
|
||||
7. **Gitea is the system of record.**
|
||||
Client work, templates, playbooks, and decisions live in the repo under the documented paths. Do not keep the “real” version only in chat or email.
|
||||
|
||||
---
|
||||
|
||||
## 3. Where everything lives
|
||||
|
||||
| What | Path |
|
||||
|------|------|
|
||||
| Repo root / mission | `README.md` |
|
||||
| Path to PoC (master sequence) | `docs/architecture/path-to-poc-sequencing.md` |
|
||||
| Economics guide | `docs/architecture/economics-pricing-execution-guide-v1.md` |
|
||||
| Client lifecycle | `docs/business-model/client-lifecycle.md` |
|
||||
| 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` |
|
||||
| Templates | `docs/templates/` |
|
||||
| Client instances | `docs/clients/<client-name>/` |
|
||||
| GBP Snapshot HTML form | `tools/gbp-snapshot-form.html` |
|
||||
| This manual | `docs/operations/employee-onboarding-manual-v1.md` |
|
||||
|
||||
**Client artifact naming (standard):**
|
||||
- `data-inventory-v1.md`
|
||||
- `threat-register-v1.md`
|
||||
- `economics-v1.md`
|
||||
- `requirements-v1.md`
|
||||
- `workflows-v1.md`
|
||||
|
||||
Raw snapshots (when stored): `data/clients/<client>/raw/...`
|
||||
|
||||
---
|
||||
|
||||
## 4. The Path to PoC (how every engagement is sequenced)
|
||||
|
||||
Every real client engagement follows these layers **in order**. Do not skip.
|
||||
|
||||
| Layer | Name | What you produce | Human gate |
|
||||
|-------|------|------------------|------------|
|
||||
| 1 | Account Intelligence | Data Inventory | Inventory accurate before Layer 2 |
|
||||
| 2 | Threat Diagnosis | Threat Register | Each threat verified/downgraded/rejected |
|
||||
| 3 | Economics & Pricing | Economics doc + pricing bands | Owner conversation required |
|
||||
| 4 | Requirements | Outcome-based requirements | Scoped to pricing band |
|
||||
| 5 | Workflow Engineering | Operational workflows | Cadence matches real business hours |
|
||||
| 6 | Agent Build & Test | Working agents on real data | Human reviews full run |
|
||||
| 7 | POC Delivery | Demo + gap doc + retainer framing | Owner has seen live draft alert |
|
||||
|
||||
**Layer 3 cannot be skipped.** Without owner economics, downstream pricing and scope are speculative and must be labeled as such.
|
||||
|
||||
Full detail: `docs/architecture/path-to-poc-sequencing.md`
|
||||
|
||||
---
|
||||
|
||||
## 5. Day-one cold audit workflow (what you actually do)
|
||||
|
||||
This is the current production procedure for a **new prospect / first assessment**.
|
||||
|
||||
### Step A — Open a client folder
|
||||
1. Create `docs/clients/<client-slug>/` if it does not exist.
|
||||
2. Add a short `README.md` with location, phone, website, layer status table, and known public sources.
|
||||
3. Copy templates into the client folder as Draft documents:
|
||||
- Data Inventory
|
||||
- (Threat Register only after Inventory is ready for human review)
|
||||
|
||||
### Step B — Public digital baseline (no owner access yet)
|
||||
Collect **only what exists**:
|
||||
- Website (live paths, broken links, contact/booking surface, NAP)
|
||||
- Public social links from the site
|
||||
- Review/directory presence (Yelp, etc.) at a factual level
|
||||
- GBP via the **GBP Snapshot Form** (see Step C)
|
||||
|
||||
Rules:
|
||||
- Public observation = **Tier 2** until owner access upgrades it.
|
||||
- Record **Snapshot Date** for every source.
|
||||
- Missing sources are gaps, not silence.
|
||||
|
||||
### Step C — GBP snapshot (required human sensor for cold audits)
|
||||
1. Open `tools/gbp-snapshot-form.html` in a browser.
|
||||
2. While looking at the Google Maps / GBP listing, fill every field (2–5 minutes).
|
||||
3. Click **Generate for Leonard** → **Copy** or **Download .txt**.
|
||||
4. Paste the full block to Leonard (or the designated audit agent) with instruction to follow:
|
||||
`docs/agents/leonard-gbp-execution-card.md` **exactly**.
|
||||
|
||||
Leonard must:
|
||||
- Map intake fields into the Inventory GBP row only
|
||||
- Fire **only** threat rules R1–R3 if conditions match
|
||||
- Not invent fields or write solutions
|
||||
|
||||
You (human) then review and approve or correct.
|
||||
|
||||
### Step D — Data Inventory (Layer 1)
|
||||
Use `docs/templates/data-inventory-template.md` and the Audit Playbook.
|
||||
|
||||
Required minimum sources:
|
||||
- GBP (or explicit “missing/unclear”)
|
||||
- Website
|
||||
- Primary social channel(s)
|
||||
- Booking/scheduling (or “not visible”)
|
||||
- Review surfaces if observable
|
||||
|
||||
Exit only when a human has signed the review gate.
|
||||
|
||||
### Step E — Threat Register (Layer 2)
|
||||
Only after Layer 1 is human-confirmed (or explicitly accepted as Draft Benchmark with documented blockers).
|
||||
|
||||
Rules from the Audit Playbook:
|
||||
- One primary fact per threat
|
||||
- Evidence Snippet must be concrete
|
||||
- Data Recency must reference inventory snapshot dates
|
||||
- No solution language (“fix the 404s” is forbidden here)
|
||||
- Severity: Critical / Major / Minor — when unsure, choose lower
|
||||
|
||||
### Step F — Stop at the gate
|
||||
Do **not** invent economics. Do **not** write requirements or workflows until Layers 2 and 3 allow it.
|
||||
|
||||
If GBP is still incomplete, either:
|
||||
- Complete the form and update, or
|
||||
- Explicitly document “GBP unresolved” as a blocker and freeze as Draft Benchmark for training only
|
||||
|
||||
---
|
||||
|
||||
## 6. How to work with agents (Leonard and others)
|
||||
|
||||
### Roles
|
||||
- **Human operator (you):** eyes on Maps/owner access, final decisions, locks, client communication.
|
||||
- **Director / lead (architecture):** sequence, standards, repo integrity.
|
||||
- **Leonard (audit agent):** form-fill and template-faithful drafting under Playbook + execution cards.
|
||||
- **Aggregator (when used):** merge sequential agent outputs; prefer stricter evidence-bound position; no scope creep.
|
||||
|
||||
### Hard limits for agents
|
||||
- Stay inside the assigned layer.
|
||||
- Never self-lock a document.
|
||||
- Never invent client revenue, WTP, or threat counts.
|
||||
- GBP ingest without the execution card is out of process.
|
||||
|
||||
### Scoring Leonard (training)
|
||||
Use the rubric in `docs/agents/audit-playbook-v1.md` (0–2 on evidence, tier discipline, scope, recency, template fidelity). Pass ≥ 7/10 with no zeros.
|
||||
|
||||
---
|
||||
|
||||
## 7. Client lifecycle (commercial path)
|
||||
|
||||
High-level path (see full doc for detail):
|
||||
|
||||
1. Prospect
|
||||
2. Qualification
|
||||
3. Initial Assessment (Layers 1–2 style work)
|
||||
4. Evidence classification
|
||||
5. Proof-of-Concept fix (low-risk, scoped, human-approved before publish)
|
||||
6. Before/After report
|
||||
7. Retainer offer
|
||||
8. Ongoing monitoring
|
||||
9. Periodic reporting
|
||||
10. Renewal / expansion
|
||||
11. Cancellation / offboarding
|
||||
|
||||
**GTM motion:** proof before retainer. We do not lead with a cold subscription pitch.
|
||||
|
||||
**Good V1 fit:** local service, owner- or small-team operated, depends on local discovery/calls/bookings, meaningful lifetime value. Priority verticals include home services, auto repair, salon/spa (non-medical), boutique fitness, and similar.
|
||||
|
||||
---
|
||||
|
||||
## 8. Economics conversation (Layer 3) — human only
|
||||
|
||||
No agent can close Layer 3 alone. You need a direct conversation with the owner covering:
|
||||
|
||||
- Current revenue baseline (owner-provided)
|
||||
- Ad spend if any (owner-provided)
|
||||
- Owner estimate of what a problem “like this” costs monthly
|
||||
- Willingness to pay ranges for:
|
||||
- **Band A:** detection only
|
||||
- **Band B:** detection + draft response
|
||||
- **Band C:** fuller escalation with recommended next action
|
||||
|
||||
If the owner declines numbers, document Tier 2 speculative and flag risk to any retainer discussion. Do not invent figures.
|
||||
|
||||
Guide: `docs/architecture/economics-pricing-execution-guide-v1.md`
|
||||
|
||||
---
|
||||
|
||||
## 9. Publish / change control
|
||||
|
||||
Anything that changes a **client-facing surface** requires human approval first, including:
|
||||
- GBP edits
|
||||
- Review replies
|
||||
- Q&A answers
|
||||
- Hours, phone, booking links
|
||||
- Website or directory updates
|
||||
- Business/service descriptions
|
||||
|
||||
Until a specific task type has a documented reliability run of **≥ 100 error-free executions**, the human gate stays on for that task type.
|
||||
|
||||
---
|
||||
|
||||
## 10. Communication standards
|
||||
|
||||
### Internal docs
|
||||
- Status header: Draft / Human Review / Locked
|
||||
- Last Updated date
|
||||
- Evidence tier on factual claims
|
||||
- Blockers listed explicitly
|
||||
|
||||
### Client-facing language
|
||||
- Separate Verified vs Indicative clearly
|
||||
- No scare tactics from Tier 2 alone
|
||||
- No guaranteed rankings, AI citations, or “we’ll get you #1”
|
||||
- Reports answer: what we watched, what changed, what we found, what we fixed/recommended, what remains at risk, what happens next
|
||||
|
||||
---
|
||||
|
||||
## 11. First-week checklist for a new hire
|
||||
|
||||
**Day 1 — Orientation**
|
||||
- [ ] Read this manual end to end
|
||||
- [ ] Read `README.md`, Agent Charter, Audit Playbook
|
||||
- [ ] Skim Path to PoC sequencing and Client Lifecycle
|
||||
- [ ] Open `tools/gbp-snapshot-form.html` and click through once (empty is fine)
|
||||
|
||||
**Day 2 — Shadow the system**
|
||||
- [ ] Read Overcome Fitness client folder end to end (`docs/clients/overcome-fitness/`)
|
||||
- [ ] Note what is Draft vs what is still blocked
|
||||
- [ ] Identify the open GBP gate and why Layer 3 is blocked
|
||||
|
||||
**Day 3 — Practice cold audit mechanics**
|
||||
- [ ] Fill GBP form against a practice listing (or Overcome Fitness)
|
||||
- [ ] Generate Leonard paste block
|
||||
- [ ] Draft or revise a Data Inventory row from the intake **without** adding solutions
|
||||
|
||||
**Day 4 — Threat discipline**
|
||||
- [ ] Write 2–3 practice threats that each contain exactly one primary fact + evidence snippet + recency + tier
|
||||
- [ ] Have a lead score them against the playbook rubric
|
||||
|
||||
**Day 5 — Gate fluency**
|
||||
- [ ] Explain aloud when Layer 1 can lock, when Layer 2 can lock, and why Layer 3 needs an owner
|
||||
- [ ] List V1 exclusions from memory
|
||||
|
||||
---
|
||||
|
||||
## 12. Current system state (so you know what is real vs aspirational)
|
||||
|
||||
**Real and usable now**
|
||||
- Mission, evidence model, operating rule
|
||||
- Full Path to PoC sequence
|
||||
- Templates for Layers 1–2–4–5
|
||||
- Audit Playbook + Leonard GBP execution card
|
||||
- GBP HTML form
|
||||
- First benchmark client instance (Overcome Fitness) in Draft
|
||||
|
||||
**Not built yet / do not pretend exists**
|
||||
- Locked production client package with full economics
|
||||
- Automated Places API pipeline (optional future)
|
||||
- Fully automated Leonard → Gitea commit loop without human facilitation
|
||||
- Standard client-facing report template (still to productize)
|
||||
- Implementation code under `implementation/` (scaffold only)
|
||||
|
||||
When in doubt: if it is not in the repo as a Locked or Active doc, it is not process.
|
||||
|
||||
---
|
||||
|
||||
## 13. Escalation
|
||||
|
||||
Escalate to the lead/director when:
|
||||
- A client asks for out-of-scope work (ads, redesign, social production)
|
||||
- Evidence is ambiguous and a Tier 1 claim is being requested
|
||||
- Owner access is required to progress and is delayed
|
||||
- An agent output invents numbers or solutions inside Layer 1/2
|
||||
- You are unsure whether something is publish-gated
|
||||
|
||||
Default action when stuck: **document the blocker, do not invent past it.**
|
||||
|
||||
---
|
||||
|
||||
## 14. Glossary (short)
|
||||
|
||||
| Term | Meaning |
|
||||
|------|--------|
|
||||
| **GBP** | Google Business Profile (Maps / local panel listing) |
|
||||
| **DOP** | Digital Operations Partner |
|
||||
| **Tier 1 / Tier 2** | Verified vs Indicative evidence |
|
||||
| **Locked** | Human-approved; safe to build the next layer on |
|
||||
| **Draft Benchmark** | Training/reference package; not client-locked |
|
||||
| **WTP** | Willingness to pay |
|
||||
| **PoC** | Proof of Concept |
|
||||
| **NAP** | Name, Address, Phone consistency |
|
||||
|
||||
---
|
||||
|
||||
**Version:** v1
|
||||
**Maintainer:** Lead / Director
|
||||
**Update rule:** When Path to PoC, Playbook, or cold-audit tooling changes, this manual must be updated in the same change set or immediately after.
|
||||
Reference in New Issue
Block a user