Skip to main content

Starter Chat Interview Decision Log

Decisions made during the founder interview on 2026-03-26. Captures reasoning for every change so future agents understand WHY, not just WHAT.

Touchpoint 1: Homepage​

Decision: Approved with required improvement Issue: No pricing CTA above the fold. Hero has no "See Plans" or "Get Started" button. Founder reasoning: A pastor who's ready to buy sees the hero and has no clear next step without scrolling through multiple sections. Agent reasoning: The most motivated visitor has no path from the first screen. Every SaaS best practice puts a CTA above the fold. Action: Add visible pricing/signup CTA to hero section.

Touchpoint 2: Pricing Page​

Decision: Approved with 4 required improvements Issues found:

  1. Hero too large — pushes pricing cards below the fold
    • Founder: "That top header is way too big"
    • Agent: Confirmed — customer has to scroll past a massive hero to see any pricing
  2. Floating card overlap design — founder wants the /terms and /contact pattern (navy gradient hero + floating card)
    • Founder: "I really like that floating card overlapping the header on /terms and /contact"
    • Agent: Design consistency across the site + brings pricing above fold
  3. Design mismatch — pricing uses brown/dark hero, other pages use navy gradient
    • Founder: Noticed inconsistency during review
  4. Default channel is "Both" not "Chat Only" — shows Starter at $49.95 instead of $14.95
    • Founder: "My issue: that pricing page defaults to showing prices for both chat and voice"
    • Agent: Found useState<Channel>("both") in PricingGrid.tsx. Violates P8.4 (default to lowest-barrier option)
    • This could cause a customer to think Starter costs $49.95, or sign up for Both when they wanted Chat

Touchpoint 3: Chatbot Product Page​

Decision: Approved (SEO page only) Issue: Agent navigated by typing URL directly. Founder: "BAD AI AGENT! NEVER do that! Would a user know our chatbot URL? No." Learning: Always trace the click path. If you can't get there by clicking from a real entry point, the page is effectively undiscoverable. The /chatbot page is an SEO landing page (Google search "AI chatbot for churches"), not part of the primary navigation journey. New rule saved: feedback_navigate_like_a_user.md

Touchpoints 4-10: Secondary Discovery Paths​

Decision: All approved as secondary/SEO paths Reasoning: The primary journey is Homepage → Pricing → Onboard. These other paths (voice page, blog, denomination pages, PewSearch admin, PewSearch church detail, direct URLs) are either SEO landing pages or cross-sell from other properties. None need changes for Starter Chat specifically.

Touchpoint 11: Onboard Form (Landing)​

Decision: Approved with required improvements Issues:

  1. Needs navy gradient hero with floating card — same pattern being applied to /pricing
    • Founder: "Let's add our new banner with the floating card on top"
  2. No trial messaging — form says "$14.95/mo" but never mentions "14-day free trial"
    • Founder: "Big time confusion... I don't recall where we are with that"
    • Agent: Confirmed trial IS active — trial_period_days: 14 in checkout code, pricing.yaml says "14-day free trial on all chat plans"
  3. Credit card expectation not set — pastor doesn't know CC is required until Stripe step
    • Founder confirmed: "We want serious customers" — CC required, but tell them upfront
    • Spec now says: "Free for 14 days, then $14.95/mo. Cancel anytime. Credit card required."

Touchpoint 12: Onboard Step 1 — Church Search (MAJOR REDESIGN)​

Decision: Complete redesign required Issues (all raised by founder):

  1. "Find Church" step label — "What does that mean to a new customer? They must be thinking... I have a church, you want me to find one now?"
  2. "Search for My Church" button — "Customers likely will not know pewsearch.com even exists. This is a mystery search."
  3. "Skip search — my church isn't listed" — "Listed on what? That is so confusing."
  4. Entire step is an internal concern — "This is nice for us to try to tie-in all our properties... but for our newest user who has a church, this would only be confusing."
  5. It's a conversion blocker — "They might expect to see add your church name and city and state."

Founder reasoning: The customer's mental model is "I'm buying a chatbot, let me type my info and move on." We're forcing them through a directory search they didn't ask for. Agent reasoning: The form was designed from an internal perspective (match to PewSearch) not customer perspective (sign up for chatbot). Action: Replace search-first UX with simple data entry. Silent PewSearch match in background.

Touchpoint 13: Confirm Church (REMOVED)​

Decision: Remove from main flow, replace with post-checkout bonus Founder idea: "I think it could be a final page (OPTIONAL). Hey we have a large church directory listing... for all clients, we're giving away a free premium listing for as long as you're a Starter member! Interested?" Agent reasoning: Brilliant reframe — turns the PewSearch connection from a gate into a gift. Zero friction to sign up for what they came for (chatbot). Directory match becomes a bonus, not a requirement. Action: Post-checkout optional page with "Claim My Listing" / "Not Right Now"

Touchpoint 14: Contact Info (COLLAPSED INTO STEP 1)​

Decision: Merge with church info into single form Founder: "Doesn't this step actually become the first step? We could just add the city and state in here." Agent reasoning: Agreed — with the search step removed, there's no reason for 3 steps. One form with church info + contact info + plan selection, then straight to Stripe. Action: Single form: church name/city/state + contact name/email/phone + backup (optional) + plan dropdown + billing toggle

Backup Contact Section​

Decision: Make clearly optional with "recommended" label Founder: "We need to make sure it is clear that this section is recommended but can be filled in later" Action: Collapsible section labeled "Add a backup contact (recommended)" with helper text: "You can add this later from your dashboard."

Plan Dropdown — Annual Toggle Bug​

Decision: Hide toggle for voice/bundle plans Issue found: When annual toggle is active, voice/bundle plans still show monthly prices with no indicator. Customer could think $49.95/mo IS the annual price. Founder: "The customer might think... why no annual option for voice?" Agent reasoning: Two options — (1) hide toggle for voice plans, (2) show explanation. Recommended option 1. Founder: "1 agreed" — don't explain infrastructure to pastors, just hide what doesn't apply. Agent reasoning: Pastors don't know or care about per-minute Cartesia costs. Hide complexity, show only what's relevant. Action: Monthly/Annual toggle only visible when a chat-only plan is selected. Disappears for voice/bundle. Reappears when switching back to chat.

Touchpoint 15: Stripe Checkout​

Decision: Approved with required bug fixes Issues found (3 bugs):

  1. Stripe product name is "CWA Chat Starter Annual" — pastors don't know what "CWA" means
    • Founder: Noticed during live review of checkout page
    • Action: Rename all Stripe products to "ChurchWiseAI [Tier] [Channel]" format
  2. Stripe description says "voice + PW's" on a chat-only plan — misleading
    • Founder: Noticed on the actual Stripe checkout
    • Action: Fix product descriptions in Stripe to accurately reflect each tier
  3. Browser back button = stuck spinner — founder hit back from Stripe, form stuck on "Setting up your Account..." forever
    • Founder: "I hit the back button and then I saw the button at the bottom saying Setting up your Account... and it's still spinning"
    • Agent: Classic form submission + redirect issue. Browser cache shows post-submission state with no recovery.
    • Action: Detect post-submission state on page load, either redirect forward to checkout or reset form. Never leave customer stuck.

Also noted: Stripe showed CA$195.28 (CAD) not $149.50 (USD) — may be test account currency config or geo-detection. Need to verify Stripe price is set in USD.

Follow-up: Customer wants to change plan from checkout

  • Founder scenario: Picked annual, saw price on Stripe, wanted to switch to monthly. Hit browser Back → stuck spinner.
  • Decision: Option 3 — BOTH a proper "Change plan or billing" link on the checkout page AND fix the browser back button.
  • Founder reasoning: The customer should have an intentional way to go back and change their selection without losing their data.
  • Agent reasoning: "Change plan" link is the designed path. Back button fix is the safety net — customers WILL hit Back regardless. Form data stored in sessionStorage so nothing is lost either way.

Touchpoint 16: Post-Checkout Confirmation​

Decision: Approved with required improvements Key change: Direct dashboard link instead of "check your email"

  • Founder: "Totally agree... that should be the play"
  • Agent: "After a pastor just committed to trying your product, 'check your email' is a momentum killer."
  • Founder also wants: Explain that the dashboard link is secure, and tell them to save the email they just received as a backup way to access it.
  • Founder: "Explain to them that the link to their website is secure... and to be sure to save a copy of the link in the email they should have just received"
  • Action: Success page shows "Go to Your Dashboard" as primary CTA, security reassurance ("Your dashboard link is private and secure"), and secondary note to save the email for future access.
  • PewSearch bonus ("Free Premium Listing!") appears as optional section on this page.
  • Testing plan: Full click-through with Stripe test cards later today to screenshot all 3 states.

Touchpoint 17: Pre-Checkout Welcome Email — REJECTED​

Decision: Remove entirely Bug: The onboard API sends sendPremiumWelcomeEmail() with a full dashboard magic link BEFORE the customer has paid. Subject line says "Your ChurchWiseAI dashboard is ready" — but they haven't entered a credit card yet. Founder: "NO! Not intentional and not correct. No pay, no play." Agent: Confirmed the code sends the email immediately from /api/onboard/route.ts (lines 239-243), before Stripe checkout. This is a security and business logic bug — the customer gets full dashboard access without ever paying. Action: Remove sendPremiumWelcomeEmail() from the onboard API. Welcome email should ONLY fire from Stripe webhook after checkout.session.completed. Optional: cart abandonment email via MailerLite (24hr delay, "Complete your signup" CTA, NO dashboard link). Real-world proof: Zewdei Gebremedhin (first organic user) filled out the onboard form, saw the Stripe credit card screen, left without paying, then found the welcome email in his inbox with a magic link to the full dashboard. He's been using it for free ever since. The founder personally offered him 3 months free beta — so his access is authorized — but the SYSTEM gave it to him before any human decision was made. The next person who does this won't have a personal invitation. Founder action: Set up Zewdei on a proper Stripe subscription with a 100% coupon for 3 months, so he's tracked as a real customer instead of floating in preview mode.

Touchpoint 18: Post-Checkout Welcome Email​

Decision: Approved with required fixes Key changes:

  1. Rename function — sendPremiumWelcomeEmail() → sendWelcomeEmail(). "Premium" is PewSearch language, not ChurchWiseAI.
    • Founder: "That was implying when we setup a premium record in PewSearch I assume? That is no longer the case."
    • Agent: Confirmed — function name is a legacy artifact from PewSearch Premium Page flow.
  2. Tier-aware content — Starter Chat email must NOT mention voice features. The function already receives plan info, needs conditional sections.
  3. Backup framing — Customer already got dashboard link on success page (Touchpoint 16). Email is the backup, not the primary access path. Say "Bookmark this email" not "Here's how to get in."
  4. Quick-start guide — "3 things to do in your first 5 minutes" tailored to Starter Chat.
  5. PewSearch listing is separate — Not part of welcome email. Only happens if customer accepted the optional bonus on the success page (Touchpoint 13).

Touchpoint 18B: Premium Listing Email (NEW)​

Decision: Approved — new email to build Founder: Listing email should come from hello@pewsearch.com since it's a PewSearch product, not ChurchWiseAI. Agent: Confirmed PewSearch sends from hello@pewsearch.com (per pewsearch CLAUDE.md and existing email code). Flow: Only sent if customer clicked "Claim My Listing" on the post-checkout bonus page. Includes listing URL, dashboard link (same auth token), and next steps for customizing their listing. NOT sent if they chose "Not Right Now."

Touchpoints 20-23: MailerLite Trial Sequence​

Decision: Approved with required fixes Issues found:

  1. No opt-in — system auto-subscribes to MailerLite on form submit with zero consent. No checkbox on the form.
    • Founder: "I don't recall an opt-in to receive newsletters"
    • Agent: Confirmed — syncSubscriber() fires in onboard API with no consent check.
  2. Subscription fires before payment — same pre-checkout timing bug as the welcome email.
  3. Automation is DISABLED — CWA Trial Nurture was sending broken emails to Zewdei, founder disabled it.
  4. Overlap conflict — CWA Trial Nurture and Newsletter Welcome Sequence both trigger on cwa-newsletter group, causing 14 emails in 15 days. Actions:
  • Add opt-in checkbox to onboard form: "Send me setup tips and product updates" (pre-checked, optional)
  • Move syncSubscriber() from onboard API to Stripe webhook (after payment, only if opted in)
  • Rewrite all 4 emails in MailerLite with tier-aware content
  • Resolve automation overlap conflict
  • Re-enable after fixes

Country Field + Opt-In Logic​

Decision: Add required country dropdown + conditional opt-in default Founder: Pre-select opt-in for US/Canada, default unchecked for everyone else. Country must be required. Agent: CAN-SPAM (US/Canada) allows pre-checked with easy unsubscribe. GDPR (EU/international) requires explicit opt-in. Country dropdown needed anyway for billing/legal. Also confirmed: MailerLite subscription ONLY fires after Stripe payment completes (post-webhook), not on form submit. No pay, no subscribe.

Dashboard Design Principles (Questions 1-5)​

All decided during interview on 2026-03-26.

Q1: Calls tab for chat-only plans?

  • Decision: HIDE entirely from tab bar. No empty state upsell.
  • Founder: "Leaving it like this is confusing and a bit sketchy. Keep our core product clean and confusion-free."
  • New principle (P9.5): No upsell buttons in the dashboard. Use subtle "Did you know?" educational moments instead. Upsells belong on the Upgrade tab only.
  • Founder example: "Did you know you could have a voice agent to go along with your chatbot? They are quite the dynamic duo!"

Q2: Social tab for Starter?

  • Decision: HIDE entirely. It's a ShareWiseAI marketing page inside the dashboard — a separate product upsell that doesn't belong in the core product.
  • Founder: "Is this a ShareWiseAI upsell? If so, remove from here."
  • Final Starter Chat tabs: Overview, Requests, Care, Training, Settings, Upgrade (6 tabs)

Q3: Locked features — gray overlay or hidden?

  • Decision: Completely HIDDEN. No gray overlays, no "Upgrade to Pro" buttons on locked features. If a feature isn't in their plan, don't show it.
  • Founder: "Agreed" — consistent with the clean dashboard principle.
  • The Upgrade tab is the ONE place they discover what higher tiers offer.

Q4: Getting Started checklist — right 3 steps?

  • Decision: Yes. (1) Complete church profile, (2) Train your chatbot, (3) Share your chat page.
  • Founder: "Yes"

Q5: Dashboard header — show Care Page link?

  • Decision: Yes — show "View Care Page" alongside "View Chat Page" since care_enabled=true for Starter.
  • Founder: "Yes, if we have that feature available for this plan."
  • Logic: Only show links for features the plan includes.