Client Automation Workflow

TL;DR

Kaizen needs one repeatable, low-friction onboarding pipeline that takes a signed deal from "yes" to "first update shipped" without manual ops drudgery.

Stack pivot in this rev: Off Linear, off Slack, off Fizzy. Onto Basecamp + Mission Control + Campfire — all 37signals tooling for internal ops, all open or one-time license. Per-client Campfire instances become the client portal. Kai is the corporate brain.

1. Principles

2. Generic onboarding workflow

3. Applied per product

4. Automation spec

4.1 Intake schema (multi-product, v1.1)

client_name: string (required)
primary_contact_name: string (required)
primary_contact_email: email (required)
primary_contact_phone: string (optional)
billing_email: email (required)
company_size: enum [1-10, 11-50, 51-200, 201-1000, 1000+]
products_interested: MULTI-SELECT [website, seo_geo, kai_corporate_brain, other]
budget_range: enum [<10k, 10-25k, 25-50k, 50-100k, 100k+]
timeline_urgency: enum [yesterday, this_month, this_quarter, exploratory]
how_did_you_find_us: string
decision_makers: string
success_criteria_3mo: textarea

Conditional fields load per selected product (see §3). SEO/GEO additions: target keywords, geographic markets, existing rankings, current tooling, content production capacity.

4.2 Webhook contracts

Intake submission → Mission Control

POST https://mission-control.kaizenailab.com/api/onboarding/intake
Headers: X-Intake-Signature: <hmac>
Body: { submission_id, fields: { ...schema... } }
Response: 200 { client_id, supabase_row_id, ops_message_ts }

PandaDoc contract-signed → Mission Control

POST https://mission-control.kaizenailab.com/api/onboarding/contract-signed
Headers: X-PandaDoc-Signature: <hmac>
Body: { document_id, client_id, signed_at, pdf_url }
Response: 200 { provisioning_run_id }

Basecamp webhook (bi-directional sync) → Mission Control

POST https://mission-control.kaizenailab.com/api/sync/basecamp
Headers: X-Basecamp-Webhook-Token: <signing_secret>
Body: { kind: 'todo_created' | 'card_moved' | ..., recording: {...} }
Response: 200

4.3 Provisioning state machine

qualified
    ↓ (Don approves contract send)
contract_sent + intake_sent
    ↓ (PandaDoc webhook)
signed
    ↓ (provisioner picks up — does NOT wait for intake)
provisioning
    ↓ (all steps succeed)
provisioned
    ↓ (kickoff held)
active
    ↓ (engagement ends)
offboarding
    ↓ (90-day archive complete)
archived

Intake fields land async and trigger personalization passes. Failure states: provisioning_failed → Campfire #ops-alerts; contract_expired → re-send.

4.4 Key API calls

Basecamp — create per-client project

curl -X POST https://3.basecampapi.com/${ACCOUNT_ID}/projects.json \
  -H "Authorization: Bearer ${BASECAMP_TOKEN}" \
  -H "Content-Type: application/json" \
  -H "User-Agent: Kaizen Provisioner (don@kaizenailab.com)" \
  -d '{"name":"Kaizen × {Client Name}","description":"{summary}"}'

Basecamp — invite client as client-tier user

curl -X PUT https://3.basecampapi.com/${ACCOUNT_ID}/projects/${PROJECT_ID}/people/users.json \
  -H "Authorization: Bearer ${BASECAMP_TOKEN}" \
  -d '{"grant":[{"email_address":"{client_email}",
                 "name":"{client_name}",
                 "title":"Client",
                 "company_name":"{client_company}"}]}'

Campfire — install Kai into per-client instance

# Currently manual via Campfire admin UI (~30 sec):
# 1. Log in to {slug}.kaizenportal.com as admin
# 2. Bot section → Add bot → Name: "Kai",
#    Webhook URL: https://kai-{slug}.kaizenailab.com/webhook
# 3. Campfire generates per-room URLs for Kai to post unprompted
# 4. Save URLs into Supabase clients.kai_room_urls (JSON map)

Campfire — Kai posts to a room

curl -X POST "https://{slug}.kaizenportal.com/rooms/{room_id}/bot/{bot_token}/messages" \
  -H "Content-Type: text/plain" \
  --data "Hello — Kai here. What can I help with?"

Cloudflare Pages (website clients)

curl -X POST "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/pages/projects" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  -d '{"name":"{slug}-site","production_branch":"main"}'
# Staging at {slug}.pages.dev (native CF subdomain — no custom DNS)

Supabase Management (Kai)

curl -X POST https://api.supabase.com/v1/projects \
  -H "Authorization: Bearer ${SUPABASE_MGMT_KEY}" \
  -d '{"name":"kaizen-{slug}","region":"us-west-1","plan":"pro"}'

4.5 Agent ownership (Hermes runtime)

5. Build sequence

1. Week 1 — Basecamp adoption. Migrate Kaizen ops Linear → Basecamp. Connect MC as bi-directional sync. Dogfood the canonical store.
2. Week 2 — Custom intake form. intake.kaizenailab.com + Supabase clients + ops notifications.
3. Week 3 — Contract automation. SOW auto-draft + PandaDoc + parallel contract/intake fire pattern.
4. Week 4 — Provisioning state machine. Basecamp project + Cloudflare + welcome email.
5. Week 5 — Internal Campfire migration. Stand up Kaizen Campfire, migrate Hermes agents, retire Slack.
6. Week 6 — Per-client Campfire portal. Automate Docker deploy for {slug}.kaizenportal.com. Carson's build slots in here.
7. Week 7 — Kai-specific provisioning. Per-client Hermes + Supabase + Kai bot install.
8. Week 8 — Off-boarding automation.

6. Open decisions for Don (v1.1)

Resolved (no longer open)

• ✅ Intake platform: custom intake.kaizenailab.com
• ✅ Contract platform: PandaDoc
• ✅ Bot brand: Kai, white-label at top tier
• ✅ Calendar: Cal.com
• ✅ Messaging: Campfire (internal + per-client)
• ✅ Adjacent Media handoff: N/A (internal post-acquisition)

Still open

1. Top-tier white-label price point. What revenue tier unlocks Kai rename rights?
2. Per-client Campfire hosting model. One VM per client (cleanest, ~$5-10/mo) vs container density on shared VM (cheaper, more ops). Recommend per-client VM.
3. Internal Campfire migration timing. Day-1 cutover or 1-week parallel run? Recommend parallel.
4. Basecamp account structure. Single Kaizen account with all clients as projects (recommended), or per-client accounts (overkill)?
5. intake.kaizenailab.com build scope. Separate engagement, ~1 week. Confirm you want a standalone spec.

7. intake.kaizenailab.com build spec

Custom Tally/Typeform-style page, fully owned.

Tech stack

• Next.js 14+ (App Router) on Cloudflare Pages
• Supabase for submissions + product config
• Tailwind + shadcn/ui (matches kaizenailab.com brand)
• react-hook-form + zod for validation
• Resend for confirmation emails

Pages

• / — landing, brief explainer
• /start — Step 1: universal fields
• /product — Step 2: products multi-select
• /details — Step 3: dynamic conditional fields
• /review — Step 4: review
• /done — confirmation + "what happens next"

Key UX

• One question per screen on mobile, grouped on desktop
• Progress bar
• localStorage auto-save for resumable drafts
• On submit: POST to MC /api/onboarding/intake AND insert into Supabase
• Email confirmation via Resend

Branding

• Matches kaizenailab.com (dark theme default, light toggle)
• Logo + footer linking back to main site
• No Tally/Typeform watermark — fully owned

Build estimate: 5-7 working days. Recommendation: Scope as separate deliverable. Launch the workflow on Tally first if needed, swap to custom in week 2.

8. Campfire feasibility for Hermes agents

How Campfire bots work

• Each bot is a discrete entity added through the Campfire UI
• Each bot has its own name and its own webhook URL
• @mention or ping a bot → Campfire POSTs to that bot's webhook (JSON: room, user, message body)
• Bot responds with HTTP body (text or attachment) → posted to room
• For unprompted posts: each bot gets per-room URLs (token-auth in URL) to POST anytime

No documented limit on bot count. 10+ agents = 10+ bot entries. Each agent runs as its own webhook endpoint inside the Hermes runtime.

Pros vs Slack

Cons

• No native mobile app (PWA, fine for power users)
• No huddles/video
• No marketplace — everything custom webhooks
• No Slack-style threads
• Single-tenant = N deployments to operate (mitigated by automation)

Recommendation: Yes, migrate. Slack subscription savings + per-client isolation outweigh polish gap. Plan a 1-week parallel run. PWA install as default mobile path.

9. Fizzy → Basecamp kanban migration

Why the swap is clean: 37signals owns both. Basecamp's Card Table primitive is the same metaphor as Fizzy's boards. Migration = data shape, not concept shift.

Mapping

Steps

1. Export every Fizzy card with tags
2. Rewrite Mission Control's fizzy-data.ts → basecamp-data.ts using @37signals/basecamp SDK
3. Use Basecamp tags for priority/size/context; fall back to title prefix if needed
4. Bi-directional sync: Basecamp webhooks → MC cache; MC writes → Basecamp API
5. MC fallback: read-only mode if Basecamp unreachable, queue writes
6. Test on Kaizen's own ops first
7. Cut over, deprecate Fizzy, archive fizzy.do account

Effort estimate: 1-2 weeks of Carson's time. Bonus: Basecamp brings To-do lists, Messages, Docs & Files, Schedules, Check-ins — all in the canonical store. MC can surface any of them over time.