Skip to main content

Pastor cancels SermonWise Pro subscription

Persona

A pastor churning from SermonWise Pro after 2–6 months. Didn't use it enough to justify $19.95/mo, had budget constraints, switched to a different tool, or found the tradition options didn't fit. They're not angry — they still trust ChurchWiseAI — but they've deprioritized SermonWise for now. They want a clean exit and expect to come back when timing is right.

Entry points

  • Admin dashboard Settings tab: Settings → Billing → "Cancel Plan" link.
  • Stripe Customer Portal email: Invoice email → "Manage subscription" → cancel there.
  • Win-back email: "Manage Subscription" link in a win-back email.
  • Direct outreach: Pastor emails founder; founder replies with portal link (self-serve preferred).

Click-through flow

Steps

  1. Find Cancel Plan — Settings tab → Billing section: "Current Plan: SermonWise Pro," next billing date, "Cancel Plan" link (small text, not prominent).

  2. Read cancellation note and navigate to Stripe — Inline note: "Your plan will continue until [end date]. No refunds for the current period. All data preserved — reactivate anytime." "Manage My Subscription →" button creates a Stripe Customer Portal session (server-side stripe.billing_portal.sessions.create(), return URL set to /sermons/app).

  3. Stripe Customer Portal cancellation — Native Stripe interface: plan details, billing date, "Cancel plan" button. Optional Stripe exit survey. Stripe processes cancel_at_period_end: true; fires customer.subscription.updated immediately.

  4. Cancellation confirmation email — Trigger: webhook with cancel_at_period_end: true. From hello@churchwiseai.com (Resend). Subject: "Your SermonWise plan has been cancelled — [Pastor Name]." Body: plan continues until [end date], access active until then, reactivation link. DB: lifecycle_emails_sent entry with template sermon_cancellation_confirmation.

  5. Dashboard during remaining billing period — Persistent amber banner: "Your SermonWise plan cancels on [end date] — [Reactivate]." Status badge: "Cancelling." All features fully functional: can view past sermons, generate outlines if usage remains, export. "+ New Sermon" button still active.

  6. Service ends — Billing period ends; customer.subscription.deleted fires. processSubscriptionDeleted() sets user_subscriptions.status='cancelled'. Dashboard: "Cancelled" badge, read-only inputs, "Reactivate" CTA (gold, links to /pricing). Can still view all past outlines, export to Word, copy — export allowed even without active subscription.

  7. Win-back email sequenceEmail 1 (7 days after service ends): "Your sermon outlines are still here and waiting." Stats: outlines created, hours saved. "Reactivate My Account →" — soft ask. Email 2 (30 days after service ends): "We're still here when you're ready." "Choose a Plan →" and "Schedule a Call →" CTAs. After this email: no more win-back. DB: lifecycle_emails_sent entries with templates sermon_winback_7days, sermon_winback_30days.

Acceptance spec

Canonical: knowledge/acceptance/cancelled.md (27 touchpoints).

SermonWise-specific touchpoints: CX-1 (cancel location), CX-4 (dashboard during remaining period), CX-7 (post-cancellation read-only), CX-12 (confirmation email), CX-13 (service ended email), CX-14/15 (win-back), CX-16/17 (reactivation).

Success criteria

  1. Cancel in under 2 minutes without contacting support.
  2. Confirmation email arrives within minutes and clearly states end date.
  3. Can continue generating outlines until the end date.
  4. When service ends, email confirms it and offers reactivation with one click.
  5. All sermon outlines remain accessible forever in read-only mode.
  6. Can export any outline to Word even after subscription ends.
  7. Win-back emails are respectful and sparse (two total).

Known failure modes

  • Cancellation confirmation email missing. Monitor lifecycle_emails_sent for failed template sermon_cancellation_confirmation. Retry failed sends hourly for 24 hours.

  • Reactivate button goes to wrong URL. Must link to /pricing, not /checkout. Test on every deploy.

  • Read-only inputs still editable. Backend must validate: if (user_subscriptions.status === 'cancelled') { return 403 } for any generation endpoint.

  • Export blocked for cancelled users. Export should be allowed for any outline the user owns, regardless of subscription status. Remove the subscription check from the export endpoint.

  • Multiple cancellation cycles. Suppress win-back emails after the 2nd cycle to avoid spam. Monitor cancellation_count in user metadata (per spec CX-23).