Trial Extension & Save Offer UX — Chat Prompts

⬅️ Back to 6. Grow

If your B2B SaaS has a trial-to-paid funnel OR a paid plan with churn, you'll need save flows: structured UX patterns that catch customers about to churn (cancel mid-trial, downgrade, churn from paid) and offer interventions that recover some percentage of them. The naive shape: "Cancel" button → confirmation modal → done. The right shape: cancellation flow as a deliberate funnel — capture cancel reason, offer interventions matched to reason (extend trial / discount / pause / one-on-one with CSM), measure save rate, iterate. Trial-to-paid teams report 20-40% cancellation save rates; paid-tier churn save rates of 10-25%. Done well, save flows generate meaningful incremental ARR. Done badly, they're frustrating UX that pushes customers further away.

This chat walks through implementing real save flows: trial-extension, downgrade-instead-of-cancel, pause subscription, discount offers, "talk to founder" interventions, post-churn win-back, and the operational realities of measuring + iterating save offers.

What you're building

Cancellation flow with reason capture
Reason-matched intervention offers
Trial-extension UX (one-time vs admin-overridable)
Pause-subscription option
Discount-offer flow
"Talk to a human" / CSM intervention path
Post-churn win-back automation
Save-rate analytics by reason + intervention
Operational guardrails (don't over-discount; don't anger paying customers)

1. Decide the scope

Help me decide what shape of save flow to ship.

Three increasingly-deep shapes:

LEVEL 1: SIMPLE CANCEL FLOW (the simplest start)
- "Cancel" button → "Are you sure?" modal
- Optional: capture reason (single dropdown)
- Confirm → cancellation processed
- Pros: ships in 1-2 weeks
- Cons: no interventions; high churn

LEVEL 2: REASON-MATCHED INTERVENTIONS
- Reason dropdown drives offer:
  - "Too expensive" → discount offer
  - "Switching to competitor" → CSM 1:1 + competitive battle card
  - "Not using enough" → pause + re-engagement
  - "Missing feature X" → roadmap signal + waitlist
  - "Just trial-ending; need more time" → trial extension
- Save rate measured per reason + intervention
- Pros: real save rate (15-35%); customer feels heard
- Cons: 4-8 weeks; requires intervention library

LEVEL 3: ADVANCED SAVE FLOWS
- Level 2 + AI-powered personalized offers
- Multi-step intervention sequences
- "Pause + discount + check-in" stacked offers
- Post-churn win-back automation (90 days later)
- Pros: highest save rate
- Cons: 12-24 weeks; complex; risk of over-discounting

DEFAULT FOR MOST B2B SaaS:
- Year 1: Level 1 (simple cancel; capture reason)
- Year 2: Level 2 (reason-matched interventions) when churn becomes priority
- Year 3+: Level 3 (advanced) when scale justifies

Output: scope + boundary.

Output: scope statement.

2. Design the cancellation flow data model

Schema:

cancellation_attempts (
  id              uuid pk
  customer_id     uuid not null
  workspace_id    uuid not null
  triggered_at    timestamptz
  triggered_by_user uuid
  trigger_type    text  -- 'trial_ending', 'paid_cancel', 'downgrade'
  reason          text  -- 'too_expensive' | 'missing_feature' | 'switching' | 'not_using' | 'company_change' | 'other'
  reason_detail   text  -- free text
  intervention_offered jsonb  -- which offers were shown
  intervention_accepted text  -- which offer they took (if any)
  outcome         text  -- 'saved' | 'cancelled' | 'still_pending'
  saved_until     timestamptz  -- if saved, when does retention measure (e.g., 90 days)
  ltv_at_cancel   numeric  -- snapshot for measurement
)

trial_extensions (
  id              uuid pk
  customer_id     uuid
  granted_at      timestamptz
  extended_by_days int
  reason          text
  granted_by      text  -- 'self_serve', 'csm', 'support'
  prior_extensions int default 0  -- track abuse
)

save_offers (
  id              uuid pk
  workspace_id    uuid
  customer_id     uuid
  offer_type      text  -- 'discount' | 'trial_extension' | 'pause' | 'csm_call' | 'feature_waitlist'
  offer_config    jsonb  -- discount %, days extended, etc.
  status          text  -- 'pending' | 'accepted' | 'declined' | 'expired'
  expires_at      timestamptz
  created_at      timestamptz
  responded_at    timestamptz
)

INDEX (customer_id, created_at) for history
INDEX (status='pending', expires_at) for cleanup

Implement:
1. Migration for cancellation_attempts + trial_extensions + save_offers
2. RLS / multi-tenancy
3. Indexes for analytics queries
4. TypeScript types

Output: schema for tracking.

3. Build the reason-capture flow

The cancel UX should feel respectful, not adversarial.

Page: /settings/billing/cancel (for paid) or /trial/end (for trial)

Flow:

Step 1: Confirmation
- "We're sorry to see you go" (set tone)
- Brief explanation of consequences (data retention, downgrade impact)
- "Continue cancellation" button

Step 2: Reason capture
- "Could you share why?" (optional but encouraged; do not BLOCK on)
- Single-select dropdown:
  - "Too expensive"
  - "Missing a feature I need"
  - "Switching to another tool"
  - "Not using it enough"
  - "Project ended / company change"
  - "Bug / issue / poor experience"
  - "Other"
- Optional follow-up text field

Step 3: Reason-matched intervention (Level 2)
- Based on selected reason, show targeted offer
- "Continue with cancellation" always available
- Offer is one of:
  - Trial extension (free; if trial)
  - Discount offer (e.g., 30% for 3 months)
  - Pause subscription
  - 1:1 with founder / CSM
  - Feature roadmap signal + waitlist

Step 4: Final confirmation
- If accepted offer: success message; no cancel
- If declined: confirm cancel; show effective date + data retention info
- Send email confirmation either way

Don't:
- Block cancel if no reason selected (anti-pattern; illegal in some jurisdictions)
- Add multiple confirm modals (frustrating)
- Hide the "still cancel" option
- Use dark patterns (hidden buttons; complex unsubscribe)

Anti-pattern check: every step should pass the "would I be embarrassed to show this to a journalist?" test.

Implement:
1. /settings/billing/cancel page
2. Reason dropdown component
3. Per-reason intervention dispatcher
4. Confirmation flow
5. Email confirmation
6. Tracking events (each step)

Output: a flow that respects the customer.

4. Build the intervention library

For each cancellation reason, design a specific intervention.

REASON: "TOO EXPENSIVE"

Intervention: Discount offer
- Show: "We'd love to keep working with you. Here's [X]% off for [Y] months"
- Typical: 20-30% for 3-6 months (paid) or extended trial (free)
- Per-customer cap: maximum 1 discount per 12 months
- Plan-tier cap: lower-tier accepts smaller discount; enterprise rare
- Auto-apply to next billing cycle on accept
- Stripe coupon backend

Implementation:
- Determine discount tier (e.g., based on customer ARR + tenure)
- Generate Stripe coupon with one-time-use code
- Apply on next invoice
- Track in save_offers

Don't:
- Offer 90% discounts (signals desperation; trains customers to threaten)
- Offer to non-existent customers ("$100 off your $0 plan")
- Let customers stack discounts (max one active discount)

REASON: "MISSING FEATURE"

Intervention: Roadmap + waitlist
- Show: "We're working on [related feature]. Join the waitlist for early access?"
- Capture: customer email + use case + priority
- Surface to product team weekly
- If feature is on roadmap: confirm timeline
- If not: note demand; signal product need

Implementation:
- Feature waitlist sign-up
- Add to product feedback queue
- Email from PM if feature exists / timeline

REASON: "SWITCHING TO COMPETITOR"

Intervention: 1:1 with founder / CSM
- Show: "Let's chat. [Founder/CSM] will reach out within 24 hours to understand."
- Calendar booking via Calendly
- Or: "Schedule a call" CTA
- High-priority CSM ticket

Implementation:
- Calendly link with pre-filled context
- Slack alert to CSM team
- 24-hour SLA for outreach

REASON: "NOT USING IT ENOUGH"

Intervention: Pause subscription OR re-engagement
- Pause: "Pause for [1 / 3 / 6 months]; we'll reactivate when you're ready"
- Or: "Tour through the activation features you might've missed"
- Re-engagement: trigger product-tour overlay

Implementation:
- Pause logic (no billing for X months; data retained; access restored on unpause)
- Stripe pause subscription support
- Re-engagement: schedule check-in email at 30 days

REASON: "PROJECT ENDED / COMPANY CHANGE"

Intervention: Account preservation OR pause
- Show: "Pause for 3-12 months and your data is preserved"
- Or: "Account merge if you join another organization"
- Or: "Easy reactivation later"

REASON: "BUG / POOR EXPERIENCE"

Intervention: Direct line to support + (optional) discount as goodwill
- Show: "Support team will reach out within 4 hours to make this right"
- Optional: discount as goodwill ("On us; for the trouble")
- High-priority support ticket
- Often: founder-level personal outreach

REASON: "OTHER"

Intervention: Open-text + CSM follow-up
- Capture: detailed feedback
- CSM follow-up within 48 hours

Implementation:
1. Reason → intervention mapping
2. Per-intervention UX
3. Backend logic per intervention (Stripe coupon, pause, calendar, etc.)
4. Email confirmations
5. Analytics tracking per intervention

Output: tailored interventions per reason.

5. Implement trial extension UX

For trial cancel cases:

Self-serve trial extension:
- Show: "Need more time? Get [N] days extra."
- Typically: 7-14 days
- One-time per customer (not unlimited)
- Auto-apply
- Track in trial_extensions

Admin-granted extension (CSM / founder):
- CSM can grant longer extensions (30-60 days)
- For specific reasons (legal review, procurement, demo extension)
- Logged in CRM

Anti-abuse:
- Track prior extensions
- After N self-serve extensions: require talking to CSM
- Don't allow infinite extensions

UX patterns:

Auto-prompt before trial ends:
- 3 days before trial ends: in-app banner + email
- "Your trial ends in 3 days. Extend? Talk to us? Convert to paid?"

Day-of-end:
- Most prominent banner
- Last-chance offer

Post-end:
- "Trial ended" page with options:
  - Convert to paid
  - Request extension (one-time, if eligible)
  - Talk to sales
  - Cancel + export data

Implement:
1. Trial-extension UI
2. Extension eligibility check
3. Backend extension logic (extend Stripe trial; update DB)
4. CSM-grant interface (admin tool)
5. Anti-abuse tracking
6. Pre/post-trial-end UX

Output: trial extensions that work.

6. Implement subscription pause

Pause is increasingly common — alternative to cancel.

How pause differs from cancel:
- Subscription paused; no billing for paused period
- Customer keeps account access at limited / read-only level
- Data preserved
- Auto-resume at end of pause window OR customer manually resumes
- Limit: 1 pause per 12 months; max 6 months pause

Stripe support:
- Subscription pause_collection feature
- Customer's billing skips for N cycles
- Resume on schedule or manual

Customer-facing UX:

Pause options modal:
- "Pause for 1 month"
- "Pause for 3 months"
- "Pause for 6 months"
- "Custom"

What happens during pause:
- Account remains accessible (read-only) OR fully accessible (varies by product)
- Data preserved
- Some features may be disabled (e.g., new project creation)
- No billing
- Reactivation 1-click

Reminder + auto-resume:
- 7 days before resume: email reminder
- Auto-resume on scheduled date
- If customer wants to extend pause: ask before resuming

Permanent cancel:
- Pause is NOT permanent
- After max pause window: convert to cancel automatically
- Or: explicit user action to cancel

Implement:
1. Pause UX
2. Stripe pause_collection integration
3. Account-state during pause (read-only / limited)
4. Reminder + auto-resume
5. Pause-to-cancel transition

Output: pause that retains customers without billing.

7. Build post-churn win-back automation

Once a customer churns, the conversation isn't over. 5-15% can be won back.

Win-back trigger: 30, 90, 180 days post-churn

Email sequence:

Day 30: "How's it going?"
- Light check-in
- Don't sell; ask
- Mention: data is still preserved (if true)

Day 90: "Update on what we've shipped"
- Highlight features added since they left
- Address common reasons they cited
- Specific to their reason (if captured)
- Soft CTA: "Come back?"

Day 180: "Special offer"
- Discount or free month
- "Welcome back" specific offer
- Stronger CTA

After 365 days: stop unless explicitly opted in

Personalization:
- Use captured reason
- "When you left, you mentioned [reason]; here's what we've changed"

Avoid:
- Aggressive sequences (1 email/week is too much)
- Generic mass emails (lower open rate; brand damage)
- Asking them to come back without giving a reason

Tracking:
- Win-back email open / click / convert rate
- Customers who returned within 365 days
- LTV of win-backs vs. fresh-acquisition

Implement:
1. Post-churn email sequence (30/90/180 day cadence)
2. Reason-personalized content
3. Special offer at day 180
4. Tracking + analytics
5. Automatic stop after 1 year

Output: win-back that recovers some lost revenue.

8. Analytics + iteration

Save flows are iterative. Measure and improve.

Key metrics:

Cancellation funnel:
- Started cancellation: count + rate
- Selected reason: count + distribution
- Saw intervention: count + per-reason
- Accepted intervention: count + rate
- Cancelled despite intervention: count + rate
- Saved (final outcome): count + rate

Per-reason save rate:
- "Too expensive": save rate by discount
- "Missing feature": save rate by waitlist sign-up + future feature ship
- "Not using": save rate by pause vs reactivation

Long-term outcomes:
- Saved customers: do they churn within 90 days anyway? (If high: save flow is band-aid)
- Saved customers: do they upgrade later? (Great signal)
- Discount-saved customers: cohort LTV
- Pause-saved customers: who reactivates vs cancels at end of pause

Quarterly review:
- Reason distribution (changing? indicates product or market shift)
- Intervention effectiveness
- Discount cost vs LTV saved
- Iterate offers; A/B test

A/B testing:
- Test: discount % (15% vs 30% vs 50%)
- Test: trial extension length (7 days vs 14 days)
- Test: copy / tone of cancellation page
- Test: intervention order

Implement:
1. Analytics events at each step
2. Per-reason save-rate dashboard
3. Discount cost tracking
4. Long-term cohort analysis
5. A/B testing framework for offers

Output: instrumented save flows that improve over time.

9. Operational + edge cases

Walk me through:

1. Customer cancels then re-subscribes within 30 days
- "Welcome back" message
- Don't immediately offer discount (signal of weak customer)
- Restore access to original plan / data

2. Discount-saved customer churns again at end of discount
- They were trying to negotiate
- Don't re-offer discount; offer different (pause, talk to founder)
- Track: customers with multiple cancellation attempts

3. Customer abuses extensions (5 in a year)
- After 2-3 self-serve extensions: lockout from self-serve
- Require sales/CSM conversation
- Most customers don't abuse; protect the 1% case

4. Pause then customer's company is acquired
- New ownership wants to cancel during pause
- Allow cancel with data export
- Pro-rate any prior payment

5. CSM-grant extension exceeds policy
- Allow with manager approval
- Audit trail for CSM grants > 30 days

6. Customer wants to cancel mid-billing-cycle
- Pro-rate refund vs no refund: company decision
- Document clearly in ToS
- Stripe support: cancel at period end (default; standard) vs immediate

7. Annual customer wants to cancel
- They paid for full year; pro-rate refund?
- Standard: no refund mid-year (common in B2B SaaS)
- Exception: severe issue (founder approves)
- Pause until next renewal might be good middle-ground

8. Cancel-flow conversion (lost-funnel)
- Customer started cancel; abandoned mid-flow
- Re-engagement: send "Hey, finished cancellation? Or did you change your mind?"
- After 7 days: no follow-up (don't be creepy)

9. Customer tries cancel when trial; doesn't cancel; trial ends; auto-converts to paid
- Trial-end logic should consider whether customer expressed cancel intent
- If they ABANDONED a cancel mid-flow: don't auto-charge; require explicit conversion

10. International / GDPR
- Customer has explicit right to cancel; don't add friction in EU
- Cooling-off period (in some EU contexts: 14 days right of withdrawal)
- Document jurisdiction-specific rules

11. Workspace admin cancels; users still have data
- Allow data export pre-cancel (always)
- Provide grace period (30 days) for users to export
- Auto-delete after grace per GDPR

12. Workspace admin cancels by mistake
- 24-hour reversal window; one-click restore
- Useful for "oh wait, that was the prod account!"

For each: code change + UX impact + ops consideration.

Output: ops that handle real customers.

10. Recap

What you've built:

What you're explicitly NOT shipping in v1:

AI-personalized offers (Level 3; defer)
Multi-step stacked interventions (defer)
Customer-side pause-extending automation (defer)
Predictive churn-detection ML model (separate; pair with health-scoring)
Survey + qualitative interview automation (defer)

Ship Level 1 in 2 weeks; Level 2 in 4-8 weeks. Add Level 3 when scale demands.

The biggest mistake teams make: dark-pattern cancel flows. Hidden buttons; multiple confirms; force-emails; forced-feedback. These work short-term, damage brand long-term, and are illegal in many jurisdictions.

The second mistake: skipping reason-capture. Without it, you can't iterate. Even single-dropdown is 10x more useful than nothing.

The third mistake: over-discounting. 50% discount to save churn trains customers to threaten. Use sparingly; cap aggressively.