# Website Takeover
Coordinate the operating work around a website transition. Do not duplicate the technical rebuild, raw feedback, CRM, Gmail, contract, Drive, or project-ledger workflows that already have an owner.
The standard sequence is:
```text /prep-lead → Qualified → /website-refresh give-first preview → provider terms → accepted scope → access + setup + billing → cutover → stabilization ```
Boundaries
This is an **orchestrator**. It may read local customer material and prepare a readiness report, checklist, or handoff payload. It must name the next owning workflow rather than claiming to call it or silently writing its system of record.
| Need | Owner / handoff | | --- | --- | | Prospect and website-stack research | `/prep-lead <url> --web-agency` | | Opportunity stage, activity, and follow-up | `/crm` | | Give-first preview and technical rebuild | `/website-refresh --give-first` or accepted-delivery route | | Preview comments and stakeholder review | `/website-feedback` | | Accepted delivery tasks, blockers, and evidence | `/project-manager` | | MSA, SOW, signature evidence | `/client-contracting` | | Contract interpretation | `/legal-research` | | Gmail drafts, replies, and sends | `/gmail` | | Drive source documents and uploads | `/gdrive` | | Tax and invoicing research | `/accounting-research` | | Stripe customer, subscription, or payment-link creation | Patrick-owned manual task in v1 |
Do not request passwords, card or bank details, or primary-account ownership. The customer retains primary ownership and recovery control; Conversint receives named, revocable delegated access.
Start Here
1. Resolve the customer, CRM opportunity, and any mapped delivery project. 2. Read the relevant source material supplied by the user. For active delivery, load the project ledger before suggesting task changes. 3. Select the phase from the request or from the first incomplete phase in the readiness record. Read [phase gates](./references/phase-gates.md) for the exact checklist and stop conditions. 4. Read repo-root `./references/dependencies/conversint-current/references/output-paths.md` before preparing a durable customer copy. It defines the customer-artifact path and the GitHub/Drive boundary. 5. Load the matching section of repo-root `playbooks/website-takeover/Website Takeover - Operating Playbook.md`. Load `Website Takeover - Email and Collateral Library.md` only when drafting collateral. Load the internal source index only when checking provenance. 6. Report what is known, unknown, blocked, and next. Identify the owning skill for every proposed write.
Do not invent private provider terms, access status, contract terms, billing status, or customer approval from a public website or a preview.
Phases
`assess` — qualify the takeover
Use or request `/prep-lead <url> --web-agency` when a current lead brief does not already cover the web stack, likely operator, platform costs, agency signal, and website value signal. Confirm the website's job, current pain, decision authority, internal management capacity, incumbent-provider facts, and enough public material for a useful preview.
Keep the opportunity in `/crm`. Offer a CRM handoff rather than creating a delivery ledger. A lead becomes eligible for the give-first phase only after it is Qualified.
`give-first` — create a bounded preview
Route the work to `/website-refresh --give-first`. The preview uses public or clearly supplied source material and lives on a Conversint-controlled preview URL. It is a sales artifact, not a production deployment and not proof that the customer has approved claims, content, scope, or price.
Do not request operational access merely to build the preview. Do not alter DNS, the production domain, customer accounts, or the incumbent provider. If the prospect responds with preview feedback, route those comments to `/website-feedback`; keep the CRM opportunity pre-Won until commercial acceptance.
Give-first forms must be disabled or use a Conversint-controlled, clearly-disclosed non-production endpoint. Do not activate a customer inbox, WhatsApp, booking, payment, CRM, analytics, chat, or other customer integration until the engagement is accepted and the necessary access is granted.
`terms` — understand the incumbent relationship
Request the actual agreement or order form, a recent invoice, renewal notice, service inventory, and current provider correspondence. Extract only what the evidence supports: fee, cadence, included services, term, renewal, notice, final billing and service dates, termination exposure, ownership, exports, account control, and handoff timing.
Raw documents belong in the customer Drive location. Keep decision-relevant facts with source IDs in CRM before Won or the project ledger after Won. Route legal interpretation to `/legal-research`; route customer-ready cancellation or transfer language to `/gmail` as a draft.
`onboard` — move from sales to delivery
The normal gate is CRM stage Won plus accepted commercial terms through `/client-contracting`. A no-contract, verbal-commit, or pre-Won delivery exception requires Patrick to record the exception explicitly.
Before setup, separate the initial migration, ongoing website management, and any marketing or SEO work. Confirm price, billing trigger, edit boundaries, ownership, cancellation, excluded work, decision authority, and the named customer approver. Then offer `/project-manager init` or `/project-manager capture` with the source trail.
`access` and `setup` — prepare both sides
Create or tailor a customer access guide only for systems in scope. Use the playbook's access checklist and route email delivery through `/gmail`. Create the password-free account register at:
`customers/<Customer>/<Customer> - Website Account & Access Register.md`
Use [the register template](./templates/account-access-register.md). It records each known system or profile, including whether Google Business Profile and Apple Business Connect are present, the customer owner/recovery contact, delegated Conversint identity and role, credential-storage location or custodian, access status, test date, source, and next action. Do not put passwords, recovery codes, card data, or vault links in the register. The internal setup work belongs in grouped `/project-manager` tasks. Read [handoffs and artifacts](./references/handoffs-and-artifacts.md) before preparing a customer copy or task payload.
Preserve mail records: a website transition must not change MX, SPF, DKIM, or DMARC unless email work is separately authorized.
`billing` — make commercial readiness explicit
Read payment terms from the accepted agreement, not a preview or sales email. Confirm billing entity, address, contact, service description, tax treatment, payment path, and billing trigger. Add a Patrick-owned billing task through `/project-manager`; do not create a Stripe object or collect payment data.
Billing readiness blocks cutover unless Patrick records a deliberate exception. Whether payment must arrive before launch depends on the accepted agreement.
`cutover` — move the approved site to production
Use the cutover checklist in the playbook. It requires exact DNS values, registrar-specific permissions, production readiness, source backup, rollback, customer approval, form routing, an explicit analytics decision, Search Console checks, and a defined monitoring owner. For every launch, record one of these: preserve the existing measurement property, configure a customer-owned GA4 property, or tracking is explicitly out of scope. When Analytics is in scope, verify the production tag and agreed core measurement before launch.
Separate executor, independent verifier, and customer notifier. Verify DNS from more than one network or location. Keep optional directory/listing work separate from launch blockers.
Require Patrick's explicit approval immediately before a provider cancellation, production deployment, DNS or nameserver change, registrar transfer, or external launch notice. After launch, create 24-hour, 72-hour, one-week, and one-month stabilization tasks. A live site does not close outstanding billing, notification, credential-rotation, or incumbent-offboarding work.
`status` — report current readiness
Return a compact phase table: complete, blocked, unknown, owner, source, and next action. Do not mark a phase complete without evidence. Surface CRM drift as a proposed `/crm` handoff, not an unannounced update.
Artifacts and Source Handling
The generic playbook is GitHub-only. When the customer needs a copy, prepare:
`customers/<Customer>/<Customer> - Website Takeover Access Guide.md`
Keep the associated password-free register at:
`customers/<Customer>/<Customer> - Website Account & Access Register.md`
or another stable customer-named file. Commit durable Markdown through the standard helper, and keep Drive upload user-driven through `/gdrive`. Store source URLs, Drive IDs, Gmail IDs, and commit hashes beside the fact they support. Do not copy credentials, payment details, or full private correspondence into the reusable library.
Final Check
Before reporting completion, verify that:
- CRM owns pre-Won activity and the project ledger owns accepted delivery work. - `/website-refresh` owns the give-first preview or rebuild. - The customer retains domain and primary-account ownership. - Production, DNS, provider cancellation, and external notices have explicit approval evidence. - Remaining stabilization, billing, and offboarding work has an owner and task.