Skip to main content

Pastor claims Pro Website — LEGACY FLOW

⚠️ Deprecated 2026-04-18 — this flow no longer exists​

Pro Website was decoupled from PewSearch on 2026-04-18. The flow described below no longer runs — every entry point (pewsearch.com/pro-website, pewsearch.com/claim/[slug]?tier=pro_website, pewsearch.com/directory?tier=pro_website) now 301/302 redirects to the canonical churchwiseai.com pipeline.

For the current flow, read: journeys/pro-website/pastor-buys-pro-website.md — canonical cwa_pro_website pipeline on churchwiseai.com.

Why this document is preserved: it remains accurate as a historical record of the launch-shape flow (Jan–Apr 2026). Two legacy demo rows in premium_churches still carry plan='ps_pro_website' for backwards-compat test coverage. Support agents encountering a customer who says "I signed up on PewSearch" can trace the flow here. Zero real paying customers used this pipeline (per the decouple ADR — 0 conversions from 136 cold emails before decouple).

Canonical references:

Do not reference this document when writing new code, marketing copy, or support responses. It describes a frozen historical state.

Pastor claims Pro Website (legacy content preserved below)

Persona​

A solo or bi-vocational pastor of a 40–150 member church has stumbled across their church on PewSearch and noticed it shows only bare-bones scraped data — wrong hours, no staff photos, no description. They want a polished, findable web presence without the cost or complexity of a custom website build. They saw the Pro Website tier ($19.95/mo) referenced in an outreach email or the PewSearch pricing page and want the cinematic video hero, the denomination-appropriate template, and the churchname.pewsearch.com subdomain. They are comfortable with online payments but are not developers. They have a valid email address and a credit card.

Entry points​

  1. Google search — pastor searches "Grace Community Church Rockford IL" and finds the /churches/[slug] listing, which shows a "Claim this church" banner.
  2. PewSearch directory — pastor browses pewsearch.com/directory, finds their church card, clicks through to the listing page.
  3. Outreach email CTA — ChurchWiseAI cold-outreach email contains a direct link to /claim/[slug]?tier=pro_website&ref=outreach_[token]. Pastor clicks the link.
  4. Pro Website marketing page — pastor reads pewsearch.com/pro-website, clicks "Get Pro Website" which goes to /claim/[slug]?tier=pro_website.

Click-through flow​

Steps​

  1. Land on church directory listing

    • URL: https://pewsearch.com/churches/[slug]
    • What the user sees: Basic church info (name, address, phone, denomination, map), a prominent "Claim this church" banner (ClaimBanner component), a sticky bottom bar (StickyClaimCTA) on scroll, and a "Claim Your Church" link in the site header.
    • What they do: Click "Claim this church" in the banner or sticky bar.
    • Behind the scenes: Static page, no auth check. Link navigates to /claim/[slug].

  2. Arrive at claim page — select Pro Website tier

    • URL: https://pewsearch.com/claim/[slug] (or ?tier=pro_website if arriving from outreach/marketing link)
    • What the user sees: GenericClaimPage — church name/info, tier selector showing Premium ($9.95/mo) vs Pro Website ($19.95/mo) side-by-side, feature lists for each. If ?tier=pro_website is in the URL, the Pro Website option is pre-selected.
    • What they do: Select the Pro Website tier (if not pre-selected), review the feature list (cinematic video hero, denomination template, churchname.pewsearch.com, logo, chatbot), then scroll to the ClaimForm.
    • Behind the scenes: URL query param tier=pro_website (or ps_pro_website) sets the tier state. GenericClaimPage renders because no active premium_churches record exists for this slug.

  3. Fill out claim form and submit

    • URL: https://pewsearch.com/claim/[slug] (same page, form section)
    • What the user sees: Fields for Name (required), Email (required), Role (dropdown: Pastor, Associate Pastor, Office Administrator, Volunteer, Other). Submit button reads "Set up [Church Name]'s Pro Website". Price ($19.95/mo) shown in a summary card.
    • What they do: Fill in their name and email, select their role, click submit.
    • Behind the scenes: ClaimForm POSTs to /api/stripe/pre-checkout with { churchId, name, email, role, tier: 'ps_pro_website' }. The API creates a premium_churches row (status=preview, plan=ps_pro_website, admin_token generated) then creates a Stripe Checkout Session. Returns { url: <stripe_checkout_url> }. Client redirects to the Stripe URL.

  4. Stripe hosted checkout

    • URL: Stripe hosted checkout (stripe.com domain)
    • What the user sees: Product line "PewSearch Pro Website – $19.95/mo", email pre-filled, card fields, billing address. No free trial messaging. No annual option.
    • What they do: Enter credit card details, click "Subscribe".
    • Behind the scenes: Stripe processes payment. On success, redirects to the success_url: https://pewsearch.com/claim/[slug]?activated=true&token=[admin_token]. On decline: Stripe shows inline error — user retries or abandons (no state change in DB).

  5. Activation success page

    • URL: https://pewsearch.com/claim/[slug]?activated=true&token=[admin_token]
    • What the user sees: ActivationSuccessPage (Pro Website variant) — PartyPopper icon, heading "Your Pro Website is now live!", subtitle "Welcome to your new church website", next steps (choose video background, upload logo, set custom URL), and a "Set Up Your Website" button linking to /admin/[token]?tab=website. If vanity_slug is already set, a link to [vanity_slug].pewsearch.com is shown.
    • What they do: Click "Set Up Your Website".
    • Behind the scenes: Stripe webhook (checkout.session.completed) fires asynchronously — enqueued to stripe_webhook_inbox, processed by cron within ~60 seconds. Cron sets status=active, plan=ps_pro_website on the premium_churches row and sends the welcome email. The activation success page does NOT wait for the webhook — it uses the admin_token already present in the URL query param (written during pre-checkout).

  6. Welcome email (async)

    • Surface: Inbox (email from PewSearch)
    • What the user sees: Church name in subject, magic link URL (pewsearch.com/admin/[admin_token]) prominently displayed, getting-started steps (add photos, staff, hours), support contact.
    • What they do: If they didn't click "Set Up Your Website" from the success page, they can click the magic link in email to reach the admin dashboard.
    • Behind the scenes: sendPremiumWelcomeEmail() called by the cron webhook processor after status is set to active.

  7. PewSearch admin dashboard — Website tab

    • URL: https://pewsearch.com/admin/[admin_token] (defaults to Overview tab; arriving via success page link lands at ?tab=website)
    • What the user sees: Admin dashboard with tabs: Overview, Requests, Training, Website, Settings, Status. The Website tab (absent on Premium plans) is the Pro Website differentiator. Website tab contains three sections: Design (hero video grid, transition video, slideshow, logo upload, denomination template), Content (hours, staff, sermons, events, beliefs, giving), and Settings (vanity slug, featured video URL, contact CC email).
    • What they do: Choose a hero video, upload their logo, set their churchname.pewsearch.com vanity slug. Content entered here feeds directly to the public Pro Website template.
    • Behind the scenes: Saves to premium_churches JSONB columns. Public Pro Website at [vanity_slug].pewsearch.com is served by (website)/s/[slug]/page.tsx → UnifiedTemplate.tsx, revalidated every 3600 seconds (ISR).
    • Note: This is a PewSearch admin, NOT the ChurchWiseAI admin at churchwiseai.com/admin/. Pro Website is a PewSearch product. The admin token gives access to pewsearch.com/admin/[token] only. PewSearch admin does NOT include the CWA onboarding wizard (SetupGuide lives in churchwiseai-web, not pewsearch/web).

Acceptance spec​

Canonical spec: knowledge/acceptance/pewsearch-pro-website.md

The spec covers 16 touchpoints across the full lifecycle: claim page (Touchpoint 1), activation success (Touchpoint 2), marketing page (Touchpoint 3), admin Website tab — Design/Content/Settings (Touchpoints 4–7), live Pro Website public view (Touchpoint 8), mobile and SEO (Touchpoints 9–10), tab visibility vs Premium (Touchpoint 11), upgrade/downgrade flows (Touchpoints 12–14), contact form (Touchpoint 15), CWA Suite bundle entitlement (Touchpoint 16 — flagged, not yet implemented).

The Pro Website spec inherits the shared claim flow from knowledge/acceptance/pewsearch-premium.md (Touchpoints 1–8 there document the generic discovery-to-checkout path applicable to both plans).

Success criteria​

From the pastor's point of view:

  • They can navigate to pewsearch.com/admin/[token] from the magic link and see a Website tab.
  • The Website tab lets them select a hero video, upload a logo, and set a vanity slug without confusion or errors.
  • Their church appears at [vanity_slug].pewsearch.com with the cinematic video hero, no PewSearch navigation chrome, and their denomination's visual style (gold/liturgical, orange/community, navy/protestant).
  • The directory listing at pewsearch.com/churches/[slug] shows a verified badge and enhanced content.
  • A floating chatbot widget appears on their directory listing and Pro Website.
  • They receive a welcome email with the magic link within a few minutes of checkout.

Known failure modes​

  • Outreach token pollution. Testing the outreach funnel URL (/claim/[slug]?ref=outreach_[token]) against a real recipient's outreach_contacts row writes pro_website_clicked_at and advances their funnel status, corrupting campaign analytics. Always use the demo church UUID (00000000-0000-4000-a000-000000000001) with a synthetic outreach row for all funnel URL testing. See ~/.claude/projects/C--dev/memory/feedback_never_test_against_real_tokens.md.

  • Empty Pro Website demos shown to prospects. If the demo Pro Website church used in QA or public demos is missing fields (hero_video_key, logo_url, hero_slideshow_keys, beliefs, what_to_expect, etc.), a prospective pastor touring the demo sees an empty shell and loses confidence in the product. All demo premium_churches rows must be fully populated to dashboard parity standard before being shown publicly. Empty-state testing belongs in the behavioral harness with synthetic mock data. See ~/.claude/projects/C--dev/memory/feedback_no_empty_public_demos.md.

  • Webhook race on activation success. The activated=true success page loads before the Stripe webhook has been processed (cron runs every ~60 seconds). The page relies on the admin_token from the URL query param, not the DB, to show the dashboard link. If the token is absent from the URL (e.g., direct navigation or expired Stripe session), the page falls back to retrieving the Stripe session via stripe.checkout.sessions.retrieve(). This path can fail if Stripe is slow. Test success page rendering with a synthetic activated=true URL, not by hitting a real Stripe checkout session.

  • Already-claimed guard. If a church already has an active or preview premium_churches record, /claim/[slug] renders AlreadyActivePage and the claim form is not shown. This is intentional. Pastors who believe there is an error (e.g., a previous admin claimed it) must contact support — there is no self-service path to take over an active subscription.

  • Plan key comparison. Any code path that compares the plan string directly (e.g., plan === 'pro_website') will silently fail because the canonical stored key is ps_pro_website. Always use normalizePlanTier() or feature flag helpers from pewsearch/web/src/lib/premium-shared.ts. See ~/.claude/projects/C--dev/memory/feedback_never_compare_plan_directly.md.