首頁 / Skills / 品牌與行銷 / 防止流失 Churn Prevention
品牌與行銷

防止流失 Churn Prevention

Corey HainesMITSkill 語言: 英文
授權已核對不含腳本低風險
演示真實執行紀錄 · claude-sonnet-5-5 · 2026年10月
Using the churn-prevention skill, design a cancel flow and a failed-payment recovery plan for a fictional subscription app, "Ledgerly", billed through Stripe at $29/month. Monthly churn is 6%; about a third of cancellations look like failed payments. We are in the US and the EU.
Skill: churn-prevention

Ledgerly: cancel flow and failed-payment recovery plan

Baseline math (per 1,000 subscribers)

Share Subs lost/mo MRR lost at $29
Total churn 6.0% 60 $1,740
Involuntary (failed payments) ~2.0% ~20 $580
Voluntary ~4.0% ~40 $1,160

I assumed the one-third figure is net of whatever Stripe's defaults already recover today. If you have gross failure counts, I can re-baseline.

Targets at 90 days: involuntary 2.0% → ~1.2%, voluntary 4.0% → ~3.2%, total 6.0% → ~4.4%. That is roughly a 27% cut in churn. Treat these as hypotheses to test, not promises.


Part 1: Voluntary cancel flow

Flow: Settings → Cancel → one-question survey → one matched offer → confirm → post-cancel.

Survey

Title: "Help us improve: what's the main reason you're cancelling?" It is single-select with optional free text. Options, ordered by expected frequency (re-sort quarterly):

  1. Too expensive
  2. Not using it enough
  3. Missing a feature I need
  4. Switched to another tool
  5. Bugs or technical issues
  6. Don't need it right now
  7. Business closed or changed
  8. Other (free text)

Every screen has a visible "Continue cancelling" button, and the survey is skippable.

Offer matrix ($29 plan)

Reason Primary offer Fallback
Too expensive 25% off for 3 months (saves $7.25/mo, $21.75 total) Lower tier or annual plan
Not using it Pause 1–3 months, data kept, auto-resume with a reminder email 7 days before Free 20-minute setup session
Missing feature Roadmap note plus workaround guide, and a "notify me when it ships" option Pause
Competitor Short "what did they offer?" free-text, then a comparison page 25% off for 3 months
Bugs Open a support ticket with priority routing, shown before any discount One month credit
Temporary need Pause (up to 3 months) Downgrade
Business closed No offer. Offer a data export and a graceful exit. None

Guardrails

  • One primary offer and one fallback per reason. Never show a wall of options.
  • Discount cap is 30%. Allow one discount per account per 12 months, so people can't cancel repeatedly for deals.
  • Pause is capped at 3 months.
  • No guilt copy, no countdown tricks, and no confirm-shaming on the decline button.
  • Mobile-first layout, since many cancellations happen on a phone.

Confirmation and post-cancel

  • Confirmation screen: "Your access continues until [date]. You won't be charged again." Include a one-click "Undo cancellation" link, and offer a data export.
  • Cancel at period end via Stripe cancel_at_period_end.
  • Send an immediate confirmation email with a reactivation link.
  • Win-back sequence at day 7, 30, and 90 (see the emails skill). Day 30 is tied to the stated cancel reason, such as a feature-shipped notice.

Proactive layer (before they reach Cancel)

  • Usage down 50% or more for 2 weeks → "Need help?" email.
  • No login for 14 days → re-engagement email.
  • Billing page or data export visits → flag the account as high risk.
  • Renewal reminders are mostly unneeded for monthly billing. Use a value-recap email at month 3 and month 11 instead.

Measurement

  • Cancel-flow save rate target: 20–25% of cancel sessions, with offer acceptance of 15–25%.
  • Track 90-day retention of saved users separately. A save that cancels 30 days later doesn't count.
  • Pause reactivation target: 60%+.
  • First test: discount depth (20% vs 30%) and pause length (1 vs 3 months). Run one variable at a time, with feature flags such as PostHog if you use it.

Part 2: Failed-payment recovery (about 1/3 of churn)

Pre-dunning (prevent failures)

  • Turn on the Stripe card account updater (automatic) and Smart Retries.
  • Send card-expiry emails at 30, 15, and 7 days before expiry.
  • Ask for a backup payment method after the first successful renewal, not at signup.
  • EU: offer SEPA Direct Debit at checkout. It has far fewer expiry-related failures than cards.
  • EU: use setup_future_usage=off_session with SCA/3DS at signup so renewals are exempt where possible.

Retry logic by decline type

Type Action
Soft decline (insufficient funds, timeout) Smart Retries, about 4 attempts over 7–10 days, favoring paydays and the original billing time
Hard decline (closed, stolen, invalid) No retries. Go straight to "update your card".
Authentication required (EU SCA) Don't retry blindly. Send an on-session link to complete 3DS.

Keep total retries well under card-network limits.

Dunning email sequence (plain text, transactional)

# Timing Message
1 Day 0 "Your payment didn't go through. Update your card here." Direct link to the Stripe-hosted billing portal.
2 Day 3 Friendly reminder. Mention what's at stake: data, history, and reports stay safe.
3 Day 7 "Your account will pause in 3 days."
4 Day 10 Final notice, with a support contact and a reply-to for help.
  • Also show an in-app banner and a lock-on-login prompt from day 0.
  • Optional SMS or push at day 5 for users who opted in (only where consent exists).
  • Language: "your payment didn't go through", never "you failed to pay".
  • Use localized currency and language for EU customers.
  • When a customer fixes their card, retry immediately instead of waiting for the next scheduled retry.

Grace period and end state

  • Keep access (read-only after day 7) through day 10–14.
  • After that, cancel the subscription but keep data for 90 days with a one-click reactivate link.
  • Feed those users into the win-back sequence, tagged "payment failure", not "chose to leave".

Measurement

  • Payment recovery rate target: 60%+ overall (soft 70%+, hard 40%+).
  • Pre-dunning prevention target: 20% of would-be failures.
  • Track involuntary churn as a separate line item from voluntary churn.
  • Report weekly during the first month: failures, recoveries by decline code, and email-to-update conversion.

Compliance (US and EU)

I'm not a lawyer. Have counsel review before launch.

  • US: keep online cancellation as easy as sign-up. The federal FTC click-to-cancel rule was struck down in 2025, but state automatic-renewal laws (California, New York, and others) still require easy online cancel and clear renewal disclosures. This flow's single survey, one offer, and visible exit is built to satisfy that.
  • EU: a clear "cancel contract" function is required in Germany and is increasingly expected elsewhere. The EU consumer-rights withdrawal-button requirement is phasing in during 2026. Keep the cancel path to a few clicks, with no forced survey.
  • GDPR: dunning and cancellation emails are transactional. Win-back marketing needs a lawful basis or consent in the EU, so gate it accordingly.
  • PSD2/SCA: failed 3DS payments need customer action, which is why the authentication-required row above doesn't retry.

Rollout order

  1. Week 1: enable Smart Retries, the card updater, and Stripe's built-in dunning emails. Add SEPA for EU customers. Tag decline codes.
  2. Week 2: replace the default emails with the custom 4-email sequence and add the in-app banner.
  3. Weeks 2–4: build the cancel flow with the survey and the "too expensive" and "not using" offers first (the likely top two reasons), plus pause.
  4. Month 2: add the remaining reason paths, win-back emails, and the proactive risk emails.
  5. Month 3: start A/B tests and review save-offer LTV.

You can build the cancel flow in-house with the Stripe Billing Portal and a small custom screen, or buy Churnkey or ProsperStack. At $29/month, buying is probably faster if you have under a few thousand subscribers.

Next, I can draft the dunning email copy, the cancel-screen copy per reason, or the Stripe configuration and webhook handling. Tell me which you'd like first.

Real run in an isolated folder with only this skill installed. Only the Skill and Read tools were enabled, so nothing was fetched from the web and no file was written. The example is fictional. The app and its numbers are invented.

它做什麼

同時涵蓋主動流失與被動流失。主動流失方面,它設計取消流程(觸發、退出問卷、依原因動態給出的挽留方案、確認),列出挽留方案類型(折扣、暫停、換方案、專人協助)與介面模式。預測方面,它介紹風險訊號、健康分數模型與主動介入。被動流失方面,它給出整套催款體系:事前預防付款失敗、智慧重試邏輯、催款郵件序列與挽回率基準。此外還涵蓋關鍵流失指標、同期群分析、取消流程的 A/B 測試與常見錯誤。參考文件包括取消流程模式與催款手冊。

運作方式

  1. 詢問目前的流失情況、計費平台、產品與使用資料以及限制條件。
  2. 設計流程、重試與郵件方案與要盯的指標,並依每 1000 個訂閱用戶做基線試算。

適合什麼場景

流失來自主動取消或信用卡扣款失敗的訂閱制與 SaaS 團隊。

說明與風險

低風險:純指令檔,沒有腳本,不連網、不寫檔。這是會影響客戶與營收的商業建議,請對照你所在市場的消費者保護規定檢查。Skill 警告不要使用隱藏取消按鈕之類的暗黑模式,並提到美國 FTC 的「一鍵取消」要求,但歐盟、英國與美國各州的法律不同,請把它當作起點,而不是法律意見。折扣與挽留方案會吃掉利潤,先把數字算清楚。部分連結指向本套件不包含的工具指南。已用一個虛構的訂閱應用試用過一次。