Skip to main content

Visitor submits prayer request via voice agent

Persona​

A visitor or regular congregant calling to add someone to the prayer list. They may be a regular attendee, a newcomer seeking support, or calling on behalf of a neighbor. They expect the church to treat their request with care — not just file it away.

Entry points​

  • Direct prayer call: Visitor calls specifically to submit a prayer request.
  • Prayer mention mid-call: Visitor calls about event details, then mentions a prayer need. Agent pivots: "Would you like me to add that to our prayer list?"
  • Recurring caller: Regular congregant updating the prayer list monthly.

Click-through flow​

Steps​

  1. Visitor mentions prayer — Agent detects prayer-intent keywords ("pray for," "prayer list," "surgery," "worry"). Coordinator continues conversation with full attention.

  2. Agent confirms details — "I'd love to help. So you'd like us to pray for your mom — she's having surgery on Friday. What's her name?" HEAR protocol in effect: Hear, Empathize, clarify.

  3. Agent captures prayer text — "So we're praying for [Mom's Name]'s surgery on Friday — wisdom for the doctors and peace for your family. Is there anything else?"

  4. Agent repeats back for confirmation — "Okay — we're adding [Mom's Name] to our prayer list for surgery on Friday. Wisdom for the doctors, peace for your family. Your name is [Caller Name], best number is [phone]. Is that right?" If caller corrects, agent asks the unclear part again.

  5. Prayer request written to database — voice_prayer_requests row inserted: caller_name, caller_phone, prayer_request_text, source='voice', church_id, created_at, status='pending'. Write happens in verticals/church/tools.py:add_prayer_request() via LLM tool call (~500ms).

  6. Staff notification and caller confirmation — Caller hears: "Thank you for sharing that. [Church Name]'s prayer team will lift [Mom's Name] up in prayer." Email fires to escalation_contact_email with caller name, phone, request text, and dashboard link. Dashboard Requests tab updates via WebSocket.

Acceptance spec​

Canonical: knowledge/acceptance/starter-voice.md (prayer request capture, staff notification, tool execution touchpoints).

Prayer request handling is included in ALL voice tiers — no tier gating.

Success criteria​

From the visitor's point of view:

  1. Agent listens fully without interrupting.
  2. Agent repeats back the prayer request in their own words.
  3. Visitor is invited to confirm or correct.
  4. Visitor is told the prayer team will pray (not just "we'll file this").
  5. Call feels warm and personal, not transactional.

From the pastor's point of view:

  1. Email arrives within 3 seconds.
  2. Email includes caller phone number (can follow up).
  3. Prayer text is clear and actionable.
  4. Dashboard Requests tab shows requests by date, source, and status.

Known failure modes​

  • Prayer intent not detected. If LLM doesn't pivot on "pray for healing," visitor feels unheard. Verify system prompt includes: "If visitor mentions prayer, health, or spiritual need, ask: 'Would you like me to add that to our prayer list?'"

  • Caller name or phone not captured. Coordinator must always ask for name and best callback number. Write null values produce unusable prayer requests.

  • Prayer text incomplete. If Deepgram fails mid-request, text is truncated. Agent should always ask "Is there anything else you'd like us to pray for?" as a closing gate before writing.

  • Duplicate prayer requests. If the same caller submits identical text on the same day, the second insert should be silently dropped. Verify deduplication check runs before Supabase write (not after).

  • Staff notification never arrives. If escalation_contact_email is unset or email service is down, the request sits in DB unnoticed. Test notification delivery after each onboarding.