Skip to main content

Pastor buys a Pro Website

Persona​

A solo or bi-vocational pastor of a 40–200 member church is tired of wrestling with Wix / Squarespace / an ancient PHP site that a volunteer built in 2014. The church's online presence is embarrassing — wrong service times, no staff photos, no way for first-time visitors to get oriented before walking in the door. The pastor sees a ChurchWiseAI cold-outreach email, a Google ad, or hears about it from a peer, lands on churchwiseai.com/pro-website, and wants a polished, denomination-appropriate site shipped within a weekend. Tech comfort is low-to-moderate. Price sensitive but willing to pay $14.95–$19.95/mo if setup is truly 10 clicks. Decision cycle is often same-session when the pricing + setup wizard are transparent.

Entry points​

  1. /pro-website — ChurchWiseAI marketing page for Pro Website. Hero video, 10-click setup promise, pricing, FAQ, CTA. This is the canonical landing surface.
  2. /pricing — channel toggle to "Website" surfaces the $14.95/mo site-only and $19.95/mo bundled-with-chat cards.
  3. Cold outreach email — church-outreach campaign emails link directly to /pro-website or /onboard?plan=cwa_pro_website. No PewSearch starter-kit intermediate.
  4. Organic Google search — "church website builder for pastors" → /pro-website.
  5. Referral from another pastor — direct URL share.
  6. Legacy PewSearch links (historical — all redirect) — anything previously pointing at pewsearch.com/pro-website or pewsearch.com/claim/[slug]?tier=pro_website now 301/302-redirects to this flow per the 2026-04-18 decouple ADR. A reader following an old bookmark lands here.

Click-through flow​

Steps​

  1. Step 1 — Lands on /pro-website

    • URL: https://churchwiseai.com/pro-website
    • What the user sees: pain-led hero (not sermon voice), 3-minute demo video of the setup wizard, "10 clicks from now your church has a website" promise, pricing, denomination template carousel, FAQ, "Get Started" CTA.
    • What they do: watches video or scrolls to pricing, clicks "Get Started" or "See Pricing."
    • Server-side: static page render (churchwiseai-web/src/app/pro-website/page.tsx). No auth.

  2. Step 2 — Reviews pricing

    • URL: https://churchwiseai.com/pricing?channel=website
    • What the user sees: two cards — Site-only $14.95/mo, Bundled (Site + Chat Starter) $19.95/mo. Annual toggle shows equivalent yearly pricing (~1 month free, annual waives custom-domain setup fee on bundled).
    • What they do: picks a tier, clicks "Get Started."
    • Server-side: CTA appends ?plan=cwa_pro_website (or cwa_pro_website_bundle) to the onboard URL.

  3. Step 3 — Onboard form

    • URL: https://churchwiseai.com/onboard?plan=cwa_pro_website
    • What the user sees: church name, pastor name, email, phone, denomination (dropdown: non-denom, Baptist, Methodist, Catholic, Lutheran, Presbyterian, Pentecostal, Anglican, Orthodox, other), desired vanity slug (defaulting to a slug derived from church name + city, with availability check).
    • What they do: fills fields, clicks "Continue to Payment."
    • Server-side: form data persisted in session; vanity slug uniqueness validated against premium_churches.vanity_slug before submit.

  4. Step 4 — Embedded Stripe Checkout

    • URL: https://churchwiseai.com/onboard/checkout (embedded checkout — not Stripe hosted)
    • What the user sees: the ChurchWiseAI-branded page wrapping a Stripe embedded checkout component. Product: "ChurchWiseAI Pro Website" $14.95 or $19.95. No setup fee (unless adding a custom domain — that's a separate $49.95 one-time charge later, bundled-tier only).
    • What they do: enters card, clicks "Subscribe."
    • Server-side: Stripe creates subscription. On success, redirects to /onboard/return?session_id=....

  5. Step 5 — Confirmation + inbox webhook

    • URL: https://churchwiseai.com/onboard/return
    • What the user sees: "Welcome to ChurchWiseAI — [Church Name]! We're setting up your Pro Website. Check your inbox in a minute for the login link."
    • What they do: reads, waits for email or clicks "Open Dashboard."
    • Server-side: POST /api/stripe/webhook verifies signature, inserts event into stripe_webhook_inbox (idempotent on stripe_event_id), returns 200 in <200ms. No provisioning work inline. See decisions/2026-04-14-stripe-webhook-inbox.md for the pattern + its post-mortem origin.

  6. Step 6 — Provisioning (server-side, 10–60s after payment)

    • No URL — background pipeline.
    • What happens: cron at /api/cron/process-stripe-webhooks fires every minute, claims the inbox event, calls processStripeEvent():
      1. provisionNewChurch() inserts premium_churches row with plan='cwa_pro_website' (or cwa_pro_website_bundle), status='active', vanity_slug from the onboard form, admin_token UUID generated.
      2. Welcome email sent via Resend with subject "Your Pro Website is ready to set up" and magic-link URL https://churchwiseai.com/admin/[token].
    • Failure handling: if provisioning throws (vanity_slug collision, email send fail), inbox row moves to failed status, retries with exponential backoff, P0 alert after max attempts.
    • Critical contract (from 2026-04-17 P0): premium_churches.plan holds the canonical Stripe tier key (cwa_pro_website). Never persist normalizePlanTier() output here — that's lossy and breaks every pattern-match query downstream. See architecture/db/plan-column-contract.md.

  7. Step 7 — First login + setup wizard

    • URL: https://churchwiseai.com/admin/[token]
    • What the user sees: dashboard with Website tab auto-selected. 10-step setup wizard prompts (denomination template, hero photo/video, service times, staff, beliefs, events, contact form, Giving link, social links, review + publish).
    • What they do: completes wizard. Wizard progress persists per step — they can leave and come back.
    • Server-side: each step writes to church_websites (or equivalent — verify against churchwiseai-web/src/app/admin/[token]/components/WebsiteTab.tsx). On final "Publish," premium_churches.website_published flips true. Public site rendered by src/app/s/[slug]/page.tsx becomes live at vanity.john316.church within seconds (SSR, no cache lag).

Then: the pastor shares vanity.john316.church on bulletins, business cards, their old website's homepage as a redirect. First-time visitors now land on a polished, denomination-appropriate site with a chat bubble (bundled tier only).

Acceptance spec​

Primary spec: knowledge/acceptance/cwa-pro-website.md — 62+ touchpoints covering marketing, checkout, provisioning, setup wizard, publish, live-site behavior, admin tabs, billing.

Tier deltas:

Plan keyPriceChat includedCustom-domain setup fee
cwa_pro_website$14.95/moNo$49.95 (bundled-tier only)
cwa_pro_website_bundle$19.95/moChat Starter bundled$49.95 (waived on annual)

See data/pricing.yaml for canonical Stripe product + price IDs.

The separate onboarding spec at acceptance/pro-website-setup-wizard.md covers the 10-step wizard inside the admin dashboard (Step 7 above). The separate cancellation spec is acceptance/cancelled.md.

Success criteria​

From the pastor's POV:

  1. Payment completes cleanly, card charged visible in their bank within an hour.
  2. Welcome email with magic link arrives within 2 minutes. Subject line is clear ("Your Pro Website is ready to set up").
  3. Magic link works first click. Dashboard opens straight to the Website tab.
  4. Setup wizard is navigable without outside help. No broken fields, no hidden requirements.
  5. Publishing makes the site live at vanity.john316.church within seconds — pastor can hit reload and see it.
  6. Public site reflects the church's denomination (right hymn-style tone, right imagery, right theology vocab) without manual tuning.
  7. No PewSearch surface appears at any point. The pastor never needs to know PewSearch exists.

Known failure modes​

  • Magic link email never arrives — welcome email send inside provisionNewChurch() can fail all 3 retries; the inbox row still marks succeeded but the pastor has no magic link. Monitor provisioning_summary on inbox rows for partial failures. Workaround: /founder/[token]/webhook-inbox dashboard surfaces these; founder can manually resend.

  • Vanity slug collision — two pastors happen to pick the same slug (e.g., firstbaptist) at near-identical moments. The onboard form's pre-check passes for both, then the second provisioning throws a unique-index violation. Inbox retry logic escalates; founder intervenes to suggest an alternate slug. Code: src/lib/provisioning/vanity-slug.ts uniqueness guard.

  • Cross-family upgrade attempted — a Chat Starter customer tries to add Pro Website via the admin Billing tab. Currently REJECTED with 400 by the isSafeLadderTransition guard shipped 2026-04-24 (FA-082 filed for the multi-item-subscription follow-up). Message: "Please email support for this change."

  • ps_pro_website plan key appearing on a new provisioning — P0 defect. All new CWA signups must be cwa_pro_website; the ps_pro_website key exists only for 2 legacy demo rows. If provisionNewChurch() ever writes ps_pro_website for a new customer, something is wrong with the checkout → webhook → plan-key mapping. See architecture/db/plan-column-contract.md.

  • Legacy PewSearch link returns 404 instead of 302 — after the 2026-04-18 decouple, pewsearch.com/pro-website and /claim/[slug]?tier=pro_website must 301/302 redirect to this canonical flow. If a pastor hits a 404 instead, the redirect config has regressed. Fix: pewsearch/web/next.config.ts — see decisions/pro-website-decouple-2026-04-18.md for the full redirect map.

  • Denomination template misfires — pastor selects "Pentecostal" but gets a nondenom template on publish. The denomination value in premium_churches must be lowercase-normalized + match a known template slug in src/app/s/[slug]/denominations/. Logs in ops_errors flag unknown denominations falling back to nondenom.