# P13 — Per-Client Onboarding SOP (this project's "deployment")

**Updated:** 30 August 2026 · There are no servers of ours to deploy. "Deployment" = taking one client from signed agreement to live receptionist, repeatably, in ≤ 2 weeks. This SOP is the productized delivery (`SPEC.md` D4); hour estimates in brackets feed the kill-criterion tracking.

---

## Stage 0 — Preconditions

Signed pilot agreement + completed intake form (`C-10`) covering: legal business name & greeting name · hours, address, services/menu with prices · booking rules (durations, buffers, staff) · escalation phone + staffed hours · owner's WhatsApp for alerts · calendar system in use (or "none" → O5 path) · tone/voice preference · language(s) — only from the LIVE column of `COMPATIBILITY.md` · market recording policy acknowledged (`SECURITY.md` §2).

## Stage 1 — Number provisioning [1–2h]

| Market | Path |
|---|---|
| **US (LLC clients)** | Buy local number in the client's area code via the platform (~$2/mo). Client sets **conditional forwarding** on their existing line: busy / no-answer-after-N-rings / after-hours → our number. Client's number stays untouched (D6) |
| **BD** | Default: **WhatsApp Business Calling** on the client's WhatsApp Business number (call button + ads entry points); optionally plus forwarding from their GP/Robi line where the client accepts forwarding charges. No Twilio BD number at pilot (`COMPATIBILITY.md`) |
| **Gulf (partner-led)** | WhatsApp Business Calling only at pilot. No UAE VoIP numbers — regulatory, non-negotiable (`COMPATIBILITY.md`) |

Record the exact forwarding activation AND deactivation dial codes for the client's carrier in the runbook — the deactivation code is the rollback plan.

## Stage 2 — Platform configuration [3–5h, from template]

1. Clone the vertical template (`SPEC.md` §3) into a client-named workspace/agent.
2. Load the knowledge pack from the intake form. Rule: **only owner-confirmed facts** enter the pack — no scraping their old website for prices.
3. Set voice + language; set business-hours schedule (drives the after-hours behaviour switch); set recording/transcript policy per market.
4. Configure escalation targets (D8): staffed-hours transfer number, after-hours alert route.
5. Register the config in our template repo per the portability rule (`API_CONTRACT.md` §6).

## Stage 3 — Integrations [2–4h]

Calendar per `API_CONTRACT.md` §2 (platform-native tool first) · lead webhook per §3 (CRM → Sheet → email fallback order) · daily-summary flow per §4 (parameterize the shared n8n flow — do not fork it) · send test booking + test lead end-to-end and verify at the client's side.

## Stage 4 — QA gate [4h]

Run the full 20-call script (`TEST_PLAN.md`) on the client instance. Owner listens to ≥ 3 recorded/simulated calls and approves voice + tone in writing (WhatsApp message suffices). All-pass sheet filed. **No pass, no go-live — no exceptions, including client impatience.**

## Stage 5 — Go-live [1–2h, schedule a quiet weekday morning]

1. Walk the `RELEASE_CHECKLIST.md` gate top to bottom.
2. Activate forwarding (or publish the WhatsApp call entry point).
3. Founder makes 2 live smoke calls from an outside line: one booking, one human-transfer.
4. **Rehearse rollback with the owner live:** owner dials the deactivation code themselves, confirm calls return to the old behaviour, re-activate. The owner must experience that they can undo this alone in 30 seconds.
5. Deliver the 1-page handover doc (`C-15`): what it does, the caps, how to reach us, how to pause it, the rollback code.

## Stage 6 — Watch week [30m/day × 5]

Daily full-transcript review + same-day fixes (`TESTING.md` §2 week-1 protocol). End of week: containment + fixes summary to the owner — the first "wins" message sets the retention tone.

## Rollback (any time, any reason) [target: ≤ 30 minutes total]

1. Owner or we dial the forwarding deactivation code (US/BD) or unpublish the WhatsApp call entry (BD/Gulf) → **calls flow exactly as before us, immediately.**
2. Platform agent paused (stops minute spend); number retained ≥ 30 days in case of return.
3. Client data handling per `SECURITY.md` §5 retention rules; exports offered.
4. Log reason in `PROGRESS.md` — churn reasons are P8-gate evidence, treat them as findings.

## 5. Fresh-machine / handover note (working-agreement rule: reproducible by another person)

Everything needed to run this business from a new laptop: team vault access (`p13/*` credentials) · platform logins (Retell primary, Vapi dormant) · the template repo folder · n8n/Make account · this docs folder · per-client runbooks at `clients/<client_id>/RUNBOOK.md` (template: identity & numbers · forwarding codes · config location · integration endpoints · escalation targets · QA history · billing tier & cap). If a runbook is current, a competent stranger can service the client; keeping it current is part of every `C-2x` task, not a separate chore.