Add Chatbot for a New Church
Provision the chatbot for a church after purchase — create the organization_settings row with correct schema, configure the widget, and provide embed code to the church admin
Provision the chatbot for a church after purchase — create the organization_settings row with correct schema, configure the widget, and provide embed code to the church admin
APPROVED — Stage 1 agent research, pre-populated from the AI Front Desk Provisioning handoff (2026-05-21), the eight locked Phase-0 founder decisions, the AI Front Desk and Local Authority offer pages, the voice-agent code (resolve_route, the funeral/vet vertical pattern, moderation.py), the chatbot stream route, and the confirmed `local_business_*` production schema, then resolved in the founder Stage-2 interview (2026-05-21). Defines the EXPECTED OUTPUT — what a caller, a website visitor, and the business owner experience — for the per-business AI voice agent and website chatbot that the AI Front Desk + Local Authority packages promise. The voice agent is the church-built, multi-tenant, LIFE-SAFETY-tier LiveKit agent (one deployed agent serves church / funeral / vet / local-business). All 16 decisions (8 Phase-0 architecture/scope + 8 Stage-2 resolutions) are folded in; CLAUDE.md Rule #17 is satisfied — the customer-facing build is cleared.
How Claude models (Haiku 4.5 primary, claude-sonnet fallback) are used across the chatbot, voice agent Care Agent, content generation scripts, and the Claude CLI for batch tasks
Cal.com scheduling integration used by the chatbot and voice agent to book pastoral appointments — per-church booking link configuration and how the booking tool is triggered
End-to-end flow for a single chatbot message — moderation, agent selection, RAG retrieval, tool execution, and streaming response from /api/chatbot/stream
How the chatbot routes each incoming message to the correct specialist agent (Coordinator, Care, Stewardship, Discipleship) — intent detection, persona loading, and agent handoff logic
The 4 chatbot agent types (Coordinator, Care, Stewardship, Discipleship) — their personas, domain expertise, allowed tool sets, and how the routing system selects the correct agent
Technical architecture of the chatbot request pipeline — moderation, RAG retrieval, agent routing, tool calling, streaming response, and the LLM provider strategy (Claude primary / GPT-4o-mini fallback)
Definitive source of truth for the entire chatbot request lifecycle, from HTTP request arrival to response return. Every code path, every tool, every third-party call, every expected result. Generated 2026-04-02 from a full read of every file in the pipeline.
Durable reference for what makes a world-class agentic chatbot. Principles are permanent; vendor/model choices are pluggable and must be re-evaluated quarterly.
Multi-layer content moderation for the chatbot — blocklist patterns, LLM-based abuse detection, user restriction tracking, and crisis escalation to 988 / church staff
Index of chatbot ops runbooks — provision new churches, debug responses, manage knowledge base content, handle care escalations, and disable/suspend chatbots
Product overview of the ChurchWiseAI Chatbot — ministry-focused AI assistant for churches that handles visitor care, prayer requests, pastoral appointments, and church-specific Q&A
How chatbot capabilities are gated by plan tier (Starter/Pro/Suite) and context (PewSearch demo, Pro Website, standalone) — tool availability, agent access, and anti-cannibalization rules
Design for deferring empathy-sensitive tool execution so HEAR protocol is structurally enforced in chatbot responses
All 39 chatbot tools organized by category and plan tier — prayer request capture, pastoral appointments, event registration, giving info, visitor contact, and church-specific lookups
Three chatbot UX surfaces — hosted Care Hub (/care/[slug]), embedded chat widget (/chat/[slug]), and agent-specific pages — plus the HEAR pastoral conversation protocol
JavaScript embed widget configuration — script tag installation, positioning options, color theming, CORS requirements, and the "Powered by ChurchWiseAI" branding rules by tier
Diagnose chatbot problems — wrong responses, tools not saving, widget not loading, LLM errors — using Vercel logs, Supabase queries, and the RAG debug flow
Status
Temporarily disable or fully suspend a church's chatbot via organization_settings — for non-payment, debugging, church request, or policy violation
Respond to a Care Agent escalation notification — review the conversation, contact the church admin, follow up with the person in need, and log the outcome
Decision
Review and action prayer requests from voice_prayer_requests (shared by voice + chatbot) — triage by urgency, notify church pastoral staff, and log follow-up completion
Everything that happens from "pastor hears about ChurchWiseAI" through "visitor sends first message or call is answered." Covers the church admin setup journey (Track A) and the visitor discovery journey (Track B), and traces how admin-entered config flows into every AI response.
How the ChurchWiseAI chatbot widget is embedded in Pro Website pages — tier-based feature restrictions, the anti-cannibalization rules, and the upgrade prompt for Pro Website-only churches
Supabase SQL queries for product metrics — chatbot conversation counts, voice call volume, ITW page views, premium church counts, and cross-property revenue summary
Status
Add or update FAQ and knowledge base entries in unified_rag_content for a specific church — SQL inserts, embedding generation, and verifying the chatbot answers correctly
Update the product_knowledge table that is injected into chatbot and voice agent prompts at runtime — when pricing, features, or flows change, update here for immediate effect