Skip to main content

Multi-Item Self-Serve — Founder Design Interview

Date: 2026-04-25 Format: Agent-proposed design with industry-standard rationale; founder approved en-bloc. Goals (founder-stated): (1) Best UX — easy to find / easy to use. (2) Upsell, but not over-the-top. Output: knowledge/acceptance/multi-item-self-serve.md (the canonical spec).

This file captures the design rationale for future agents and reviewers. The acceptance spec is the source of truth for tests; this file explains why each choice was made.

How this interview ran​

The agent proposed an end-to-end design based on what mature multi-product SaaS companies do (Stripe Billing, HubSpot Hubs, Apple App Store Subscriptions, Cal.com, Spotify, Netflix, Notion, Slack), then justified each decision with the relevant industry pattern. Founder approved all 10 decision points without veto.

Decision 1 — Add-Product CTA placement​

Question: Where do customers find the "Add Voice / Add Chat / Add Website" CTAs?

Choice: Single canonical home — the existing "Upgrade" tab is renamed to "Subscription" and now hosts both add and remove flows.

Rationale: Stripe Billing, HubSpot, and Cal.com all funnel both flows through one "Plan & Billing" page. Splitting add vs. cancel across Settings + Upgrade increases support tickets ("where do I cancel?"). One tab; customer learns it once. Tab-name change "Upgrade → Subscription" is one string update — no IA disruption.

Considered + rejected:

  • Per-product card on Overview tab (kills the dedicated subscription home, harder to discover both add and cancel)
  • Settings tab (most customers already go to Settings looking for billing — doable but Upgrade-tab pivot is faster)

Decision 2 — Cancel-this-product CTA placement​

Question: When customer wants to cancel ONLY their voice (not whole account), where is that?

Choice: Same Subscription tab. Top section "Your active products" shows one card per active product. Cancel rendered as a small gray text-link on each card — NOT a primary button.

Rationale: Apple App Store and Spotify pattern — cancel must be findable but visually de-emphasized to prevent fat-finger churn. Primary visual weight goes to the Add CTAs (which we want them to engage with) and the Resume button (when applicable). Cancel is recoverable but understated.

Decision 3 — Cancel confirmation modal copy​

Question: What does the cancel confirmation modal say?

Choice: Direct + warm, no HEAR/pastoral framing.

"Voice will keep working through Oct 12. You won't be charged again for Voice — your other products continue. You can re-add Voice anytime."

Below the body: small text link "Issue we could fix? Email john@churchwiseai.com"

Rationale: Pastoral/HEAR tone in cancellation reads as guilt-tripping the customer. HEAR protocol applies to ministry conversations, not commerce. Apple, Google, and most reputable subscription products keep cancel copy direct and functional. The retention escape-hatch is a soft offer (not a wall) — customer can email if there's something we can fix, but the cancel button is one click away.

Decision 4 — Telnyx phone number warning on voice cancel​

Question: Should the cancel modal warn that the church phone number is held for 30 days then released?

Choice: YES — explicitly surface in the cancel modal, voice-only.

"Your church's phone number ([+1-XXX-XXX-XXXX]) is reserved for 30 days. Re-subscribe within 30 days and you keep the same number. After 30 days the number returns to availability and may be reassigned."

Rationale: Twilio + Google Voice both surface phone-number lifecycle explicitly. Customers hate losing phone numbers more than losing the service — being upfront builds trust and prevents the "I cancelled and lost my number" support ticket that's much harder to recover from than the "I want to keep my number" objection at cancel time.

Decision 5 — LAST_REMAINING_PRODUCT 409 UX​

Question: Customer tries to cancel their only active product. What do they see?

Choice: Inline modal error + single CTA to full-account cancel flow.

Modal swaps body to: "Voice is your only active product. Cancelling Voice means cancelling your whole subscription." Two buttons: primary navy "Keep Voice" + secondary outline "Go to Account Cancellation →"

Rationale: Stripe Billing pattern. Auto-redirect (option B) is jarring — customer loses context. Inline "cancel my whole account" (option C) skips the deeper full-account cancellation confirmation flow which captures additional data (e.g., for the cancelled.md spec touchpoints). Inline error + button to canonical cancel flow keeps the customer in control of intent.

Decision 6 — ANNUAL_MIXING_NOT_SUPPORTED 400 UX​

Question: Annual customer tries to add a product. The route returns 400. What do they see?

Choice: Hide the Add CTAs entirely for annual customers. Replace with inline note pointing to email-support.

"Adding services to an annual plan needs a manual switch to monthly billing. Email john@churchwiseai.com — usually same-day."

Rationale: Industry pattern when a feature isn't available for a plan: HIDE it, don't show-then-error. Annual customers never see "Add Voice" → no broken-flow UX, no error path to design, no error path to test. The inline note provides a clear escalation channel. Cancel functionality (REMOVE) works fine for annual customers — only ADD is gated.

Decision 7 — Pending-cancellation badge state + Resume​

Question: Between marking-for-cancel and the sweep cron actually dropping the item, how does the dashboard reflect this state? Can the customer un-cancel?

Choice:

  • Badge color: AMBER / yellow-warning (not red — cancellation is not an error state)
  • Badge text: "Ends [Oct 12]" with concrete date (scannable, actionable)
  • "Resume [Product]" primary button on the card — yes, customer CAN un-cancel before sweep runs

Rationale: Apple, Spotify, Netflix all use amber/yellow + concrete date language. Resume is a major retention win — published SaaS data: 15–25% of "cancel for now" decisions reverse when offered Resume. Customer-experience win is huge for ~30 min of additional implementation (one new endpoint POST /api/stripe/resume-product). This is the kind of "delight" moment that converts a churn into a save without manipulating the customer.

Decision 8 — Tier gate on self-serve​

Question: Can ALL tiers (Starter / Pro / Suite) self-serve add/remove, or only Pro+?

Choice: ALL tiers can self-serve (Starter, Pro, Suite — both monthly and annual).

Rationale: Locking Starter behind email-only support is exactly the wrong direction. Starter is your highest-churn-risk segment; friction at cancel/manage is what makes them stop coming back. All major SaaS allow self-serve at every tier. Email-support remains a backup channel, not a gate.

Decision 9 — Setup-fee transparency on Add​

Question: When customer adds Voice (which has $49.95 setup), how is the charge shown?

Choice: Itemized line-by-line with bold total.

"Today: $49.95 setup + $18.31 prorated voice = $68.26" Small "(?)" tooltip on "prorated" with explainer of the proration math.

Rationale: Stripe Billing, Cal.com, and every reputable subscription product itemizes. Hidden combined totals trigger post-purchase regret + chargebacks. Transparency at confirm-time is the highest-leverage moment to build trust.

Decision 10 — Industry-standard adds (founder didn't ask, agent proposed)​

The agent surfaced four additional UX details that the original 9 questions didn't cover. Founder approved all four:

10a. Success toast after Add​

"Voice activated! Your phone number: +1-XXX-XXX-XXXX. Setup instructions emailed to [admin@church.com]."

Slack/Notion pattern — toast + dashboard refresh on success. Confirms the action landed and provides the next-step info (phone number) without requiring an inbox check.

10b. Email confirmation on every add/remove/resume​

Stripe Billing sends these automatically; we mirror. Required for trust + paper trail. 4 templates: Add succeeded / Cancel scheduled / Resume / Sweep dropped (period-end reached).

10c. Cancellation reason survey​

Optional 1-screen survey post-cancel-confirm. Multi-select checkboxes + free-text. Spotify, Netflix, Notion all do this. Highest-leverage line item for a solo founder — learns why customers leave without doing exit interviews. Persisted to a new cancellation_reasons table.

10d. Settings → Billing pointer​

Customers reflexively check Settings for billing. One link in Settings → "Billing & Subscription" subsection saying "Manage your subscription →" and pointing back to the Subscription tab. Single source of truth remains the Subscription tab; Settings is just discoverability.

What's NOT in this design (out of scope)​

These were considered and explicitly deferred:

  • Auto-recovery of post-sweep Resume — if the customer hits Resume after the sweep cron already dropped the item, current behavior returns 410 "Cancellation already processed. Re-add from the Add a service section." Phase 7+ may add auto-re-add.
  • Annual → monthly self-serve switch — currently founder-handled via email. Could be a future flow.
  • Cross-tier upgrade within a product (e.g., Starter Chat → Pro Chat in one click) — uses the existing /api/stripe/church-checkout swap path; not in Phase 6 scope.
  • Bulk operations — no use case at current customer volume.

What this enables​

This spec unlocks Phase 6 of FA-082 (the customer-facing UI for the routes that shipped in Phases 4 + 5). Build sequence is in knowledge/acceptance/multi-item-self-serve.md §12. Tests against this spec are in e2e/multi-item-self-serve.spec.ts (TBD) per §11.

After Phase 6 ships and is verified in production, Phase 7 flips ENABLE_MULTI_ITEM_ADDS=monthly to expose the routes to real (non-demo) customers.