Skip to content
SiteSwarm Platform Documentation

Client Intake Checklist

Post-Discovery Client Intake, KYC & Scope of Work Checklist

Lifecycle Scope & When to Use This Runbook

This checklist is not a cold pre-call form sent before talking to a prospect. It is completed after the initial discovery conversation with the client (CLIENT_INTAKE_AND_ONBOARDING.md) to synthesize raw conversation notes into structured Know-Your-Customer (KYC) records and a clear Scope of Work (locations, web properties/sites, and business-specific workflows) before engineering begins.

1. Know Your Customer (KYC) & Business Identity

  • Official Legal Entity Name & Structure:
  • Public Trade / Brand Name (DBA):
  • Primary Stakeholder(s) & Decision-Maker Contact Info:
  • Authorized Technical / Domain Contact (who controls domain registrar & DNS):
  • Current Domain(s) & Registrar (e.g., GoDaddy, Namecheap, Cloudflare):
  • Existing Email / Productivity Provider on Domain (e.g., Google Workspace, Microsoft 365 — must not be disrupted during DNS cutover):
  • Primary Industry / Business Category:

2. Scope of Work: Locations, Sites & Business-Specific Operations

2.1 Web Properties & Sites in Scope

  • Number of Distinct Sites / Web Properties Required:
  • Site Inventory & Purpose (e.g., primary storefront, dedicated catering portal, seasonal microsite, sister brand):
  • Target Workspace Prefix & Slugs (apps/<client-prefix>-<site-slug>/):
  • Prototype Origin & Promotion Lineage (per CLIENT_INTAKE_AND_ONBOARDING.md Phase 3):
    • Originated from pre-awareness edge prototype? [ ] Yes / [ ] No (Greenfield Intake)
    • Source prototype workspace: apps/proto-<slug>/
    • In-place Git move executed (git mv apps/proto-<slug> apps/<client-prefix>-<site-slug>): [ ] Verified (commit pedigree preserved)
    • Dedicated Cloudflare infrastructure provisioned: [ ] D1 SQLite (<slug>-prod-d1) / [ ] R2 Bucket (<slug>-media-prod)
    • Remote CDN asset migration completed: [ ] 0 external CDN hotlinks remaining (all media ingested into client R2)
    • Domain ingress dual-route binding configured: [ ] Custom Hostname + Target Hostname per CLOUDFLARE_FOR_PLATFORMS_AND_DOMAIN_INGRESS.md
    • Zero-Lockout Data Portability verified: [ ] Clean SQLite D1 & R2 export tested (CLIENT_OFFBOARDING.md / #207)

2.2 Physical Locations & Service Footprint

  • Location Model (Single storefront / Multi-location / Mobile service area / Hybrid):
  • Addresses, Operating Hours & Phone Numbers per Location:
  • Seasonal, Weather, or Holiday Schedule Patterns:

2.3 Business-Specific Workflows & Customer Journey

  • Core Revenue Drivers & Primary Customer Actions (e.g., walk-in foot traffic, phone calls, quote requests, catering inquiries, appointment bookings):
  • Routine Business-As-Usual (BAU) Updates Needed by Owner (e.g., daily specials, sold-out notices, emergency closures, portfolio/menu updates):
  • Existing Software, POS, or Third-Party Systems in Use:
  • Industry-Specific Compliance, Licensing, or Disclosure Requirements:

3. Communication, Inquiry Routing & Brand Context

  • Inquiry Routing Destinations (Email addresses, SMS numbers, or webhooks per location/site):
  • Active Review & Social Profiles (Google Business Profile, Instagram, Yelp, LinkedIn):
  • Available Brand Assets (Logos, physical signage photos, product/team photography):
  • Voice, Atmosphere & Aesthetic Direction (VIBE.md notes):

4. Capability Scoping

Based on the scope of work above, identify the capabilities to connect in each site’s manifest (CAPABILITY_MANAGEMENT.md):

  • App-Hosted Capabilities (app-hosted) (e.g., dedicated CMS instance for routine owner updates and media):
  • Platform-Hosted Capabilities (platform-hosted) (e.g., design critiques, inquiries CLIENT_INQUIRY_INTAKE_ONBOARDING.md, shared platform services):
  • Custom Capabilities (custom) (bespoke business-specific workflows or integrations to build and catalog):

5. Post-Call Synthesis & Escalation Log

5.1 Raw Discovery Conversation Notes

[Paste raw meeting notes, call transcript summary, or owner quotes here]
  • [Item]: Question requiring explicit client verification before launch.

5.3 Planned & Ratified Builder Liberties (Creative & UX Defaults)

Track creative and UX defaults adopted during prototyping or initial intake, noting client reaction during Phase 1 discovery:

Section / Component Builder Liberty Summary (Typography, Spacing, Micro-Copy, Variants) Status (Prototyped / Client Confirmed / Escalated / Modified) Notes / Client Reaction
Hero Section High-contrast headline, location-grounded subtitle, primary 1-tap call CTA. [e.g., Client Confirmed] Approved during discovery demo without changes.
Typography & Vibe Display serif heading paired with high-legibility sans body tokens (VIBE.md). [e.g., Client Confirmed] Client confirmed aesthetic match with physical storefront branding.
Micro-Copy & Polish Streamlined contact form copy with toggleable variant preview (?variant=concise). [e.g., Prototyped] Prototyped; awaiting client review on preview deployment.
[Custom Section]
  • Prototype Liberty Lineage: Ensure all creative liberties that originated in apps/proto-<slug>/ and were ratified during discovery are preserved in apps/<client-prefix>-<site-slug>/VIBE.md and component implementations.
  • Client Escalation Boundary: Any items rejected, modified, or touching commercial/legal/DNS domains must be escalated to §5.2 above.