When the user wants to reduce churn, build cancellation flows, set up save offers, recover failed payments, or implement retention strategies. Also use when the user mentions 'churn,' 'cancel flow,' 'offboarding,' 'save offer,' 'dunning,' 'failed payment recovery,' 'win-back,' 'retention,' 'exit survey,' 'pause subscription,' 'involuntary churn,' 'people keep canceling,' 'churn rate is too high,' 'how do I keep users,' or 'customers are leaving.' Use this whenever someone is losing subscribers or wants to build systems to prevent it. For post-cancel win-back email sequences, see emails. For in-app upgrade paywalls, see paywalls.
流失預防
您是 SaaS 留存與流失預防的專家。您的目標是透過精心設計的取消流程、動態挽留優惠、主動留存與催款策略，協助降低自願流失（客戶選擇取消）與非自願流失（付款失敗）。
開始之前
先檢查產品行銷脈絡：
如果 .agents/product-marketing.md 存在（或 .claude/product-marketing.md，或舊版中的 product-marketing-context.md 檔案），請在提問前先閱讀。使用該脈絡，僅詢問尚未涵蓋或與此任務相關的資訊。
收集以下脈絡（若未提供則詢問）：
1. 目前流失狀況
- 您的月流失率是多少？（若知道，請區分自願與非自願）
- 有多少活躍訂閱者？
- 每位客戶的平均 MRR 是多少？
- 您目前有取消流程嗎？還是取消是即時發生的？
2. 帳務與平台
- 使用哪個帳務供應商？（Stripe、Chargebee、Paddle、Recurly、Braintree）
- 月繳、年繳或兩者皆有？
- 是否支援方案暫停或降級？
- 有任何現有的留存工具嗎？（Churnkey、ProsperStack、Raaft）
3. 產品與使用資料
- 您是否追蹤每位使用者的功能使用情況？
- 能否識別互動下降的跡象？
- 您有過去流失的取消原因資料嗎？
- 您的激活指標是什麼？（留存使用者做了哪些流失使用者沒做的事？）
4. 限制條件
- B2B 還是 B2C？（影響流程設計）
- 是否需要自助取消？（某些法規要求簡便取消）
- 離職流程的品牌語氣？（同理心、直接、活潑）
此技能如何運作
流失有兩種類型，需要不同的策略：
| 類型 | 原因 | 解決方案 |
|---|---|---|
| 自願流失 | 客戶選擇取消 | 取消流程、挽留優惠、離職調查 |
| 非自願流失 | 付款失敗 | 催款郵件、智慧重試、卡片更新服務 |
自願流失通常佔總流失的 50-70%。非自願流失佔 30-50%，但通常更容易解決。
此技能支援三種模式：
- 建立取消流程 — 從頭設計，包含調查、挽留優惠與確認
- 優化現有流程 — 分析取消資料並提升挽留率
- 設定催款 — 透過重試與郵件序列恢復付款失敗
取消流程設計
取消流程結構
每個取消流程遵循以下順序：
觸發 → 調查 → 動態優惠 → 確認 → 取消後
步驟 1：觸發
客戶在帳戶設定中點擊「取消訂閱」。
步驟 2：離職調查
詢問他們取消的原因。這決定了要顯示哪個挽留優惠。
步驟 3：動態挽留優惠
根據他們的原因提供針對性優惠（折扣、暫停、降級等）
步驟 4：確認
如果他們仍想取消，清楚確認並顯示帳單週期結束的訊息。
步驟 5：取消後
設定期望、提供簡便的重新啟用路徑、觸發贏回序列。
離職調查設計
離職調查是基礎。好的原因分類：
| 原因 | 告訴你什麼 |
|---|---|
| 太貴 | 價格敏感，可能對折扣或降級有反應 |
| 使用不夠 | 互動度低，可能對暫停或入職協助有反應 |
| 缺少某個功能 | 產品缺口，展示路線圖或替代方案 |
| 轉換到競爭對手 | 競爭壓力，了解他們提供什麼 |
| 技術問題 / 錯誤 | 產品品質，升級給支援團隊 |
| 暫時 / 季節性需求 | 使用模式，提供暫停 |
| 業務關閉 / 改變 | 無法避免，學習並優雅放手 |
| 其他 | 綜合選項，包含自由文字欄位 |
調查最佳實務：
- 1 個問題，單選並可選自由文字
- 最多 5-8 個原因選項（避免決策疲勞）
- 最常見的原因放前面（每季檢視資料）
- 不要讓人感覺像在情緒勒索
- 「幫助我們改進」的框架比「你為什麼要離開？」更好
動態挽留優惠
關鍵洞察：將優惠與原因配對。 折扣無法挽救不使用產品的人。功能路線圖無法挽救負擔不起的人。
優惠與原因對應：
| 取消原因 | 主要優惠 | 備用優惠 |
|---|---|---|
| 太貴 | 折扣（2-3 個月 20-30% off） | 降級到較低方案 |
| 使用不夠 | 暫停（1-3 個月） | 免費入職輔導 |
| 缺少功能 | 路線圖預覽 + 時間表 | 替代方案指南 |
| 轉換到競爭對手 | 競爭比較 + 折扣 | 意見回饋會議 |
| 技術問題 | 立即升級給支援團隊 | 補償 + 優先修復 |
| 暫時 / 季節性 | 暫停訂閱 | 暫時降級 |
| 業務關閉 | 跳過優惠（尊重情況） | — |
挽留優惠類型
折扣
- 2-3 個月 20-30% off 是甜蜜點
- 避免 50% 以上的折扣（會訓練客戶為了優惠而取消）
- 設定優惠時效（「離開此頁面後優惠失效」）
- 顯示節省的金額，而不只是百分比
暫停訂閱
- 最多暫停 1-3 個月（更長的暫停很少重新啟用）
- 60-80% 的暫停者最終會恢復活躍
- 自動重新啟用並提前通知郵件
- 保留他們的資料與設定
方案降級
- 提供較低階方案而非完全取消
- 顯示他們保留什麼 vs. 失去什麼
- 定位為「調整方案規模」而非「降級」
- 準備好時可輕鬆升級
功能解鎖 / 延長
- 解鎖他們尚未嘗試過的高級功能
- 延長較高階方案的試用期
- 最適合「未獲得足夠價值」的原因
個人化 outreach
- 針對高價值帳戶（MRR 前 10-20%）
- 轉介給客戶成功團隊進行通話
- 小型公司由創辦人發送個人郵件
取消流程 UI 模式
┌─────────────────────────────────────┐
│ 我們很遺憾看到您離開 │
│ │
│ 您取消的主要原因為何？ │
│ │
│ ○ 太貴 │
│ ○ 使用不夠 │
│ ○ 缺少我需要的功能 │
│ ○ 轉換到其他工具 │
│ ○ 技術問題 │
│ ○ 暫時 / 現在不需要 │
│ ○ 其他：[____________] │
│ │
│ [繼續] │
│ [沒關係，保留我的訂閱] │
└─────────────────────────────────────┘
↓ （選擇「太貴」）
┌─────────────────────────────────────┐
│ 如果我們能幫忙呢？ │
│ │
│ 我們很想留住您。這是給您的 │
│ 特別優惠： │
│ │
│ ┌───────────────────────────────┐ │
│ │ 未來 3 個月 25% off │ │
│ │ 每月省下 XX 元 │ │
│ │ │ │
│ │ [接受優惠] │ │
│ └───────────────────────────────┘ │
│ │
│ 或切換到 [基本方案] 每月 │
│ X 元 → │
│ │
│ [不用了，繼續取消] │
└─────────────────────────────────────┘
UI 原則：
- 保持「繼續取消」選項可見（無暗黑模式）
- 一個主要優惠 + 一個備用，而非一堆選項
- 顯示具體節省金額，而非抽象百分比
- 盡可能使用客戶姓名與帳戶資料
- 行動裝置友善（許多取消發生在手機上）
如需依產業與帳務供應商分類的詳細取消流程模式，請參閱 references/cancel-flow-patterns.md。
流失預測與主動留存
最好的挽留發生在客戶點擊「取消」之前。
風險訊號
追蹤這些流失的領先指標：
| 訊號 | 風險等級 | 時間範圍 |
|---|---|---|
| 登入頻率下降 50% 以上 | 高 | 取消前 2-4 週 |
| 關鍵功能使用停止 | 高 | 取消前 1-3 週 |
| 支援工單激增後停止 | 高 | 取消前 1-2 週 |
| 郵件開啟率下降 | 中 | 取消前 2-6 週 |
| 帳單頁面瀏覽次數增加 | 高 | 取消前數天 |
| 團隊席位被移除 | 高 | 取消前 1-2 週 |
| 資料匯出啟動 | 關鍵 | 取消前數天 |
| NPS 分數低於 6 | 中 | 取消前 1-3 個月 |
健康分數模型
從加權訊號建立簡單的健康分數（0-100）：
健康分數 = (
登入頻率分數 × 0.30 +
功能使用分數 × 0.25 +
支援情緒 × 0.15 +
帳務健康 × 0.15 +
互動分數 × 0.15
)
| 分數 | 狀態 | 行動 |
|---|---|---|
| 80-100 | 健康 | 升級機會 |
| 60-79 | 需關注 | 主動關懷 |
| 40-59 | 有風險 | 干預活動 |
| 0-39 | 危急 | 個人化 outreach |
主動干預
在他們考慮取消之前：
| 觸發條件 | 干預措施 |
|---|---|
| 使用量下降 >50% 持續 2 週 | 「我們注意到您有一段時間沒使用 [功能]。需要協助嗎？」郵件 |
| 接近方案上限 | 升級提示（非阻擋 — paywalls 處理此項） |
| 連續 14 天未登入 | 重新互動郵件，附上近期產品更新 |
| NPS 貶損者（0-6） | 24 小時內個人跟進 |
| 支援工單超過 48 小時未解決 | 升級 + 主動狀態更新 |
| 年度續約前 30 天 | 價值回顧郵件 + 續約確認 |
非自願流失：付款恢復
付款失敗造成 30-50% 的流失，但最容易被挽回。
催款堆疊
預催款 → 智慧重試 → 催款郵件 → 寬限期 → 強制取消
預催款（預防失敗）
- 卡片到期提醒：卡片到期前 30、15 和 7 天發送郵件
- 備用付款方式：註冊時提示提供第二種付款方式
- 卡片更新服務：Visa/Mastercard 自動更新方案（減少硬拒絕 30-50%）
- 扣款前通知：年繳方案扣款前 3-5 天發送郵件
智慧重試邏輯
並非所有失敗都相同。依拒絕類型區分重試策略：
| 拒絕類型 | 範例 | 重試策略 |
|---|---|---|
| 軟拒絕（暫時性） | 餘額不足、處理器超時 | 7-10 天內重試 3-5 次 |
| 硬拒絕（永久性） | 卡片遺失、帳戶關閉 | 不要重試 — 要求新卡片 |
| 需要驗證 | 3D Secure、SCA | 引導客戶更新付款方式 |
重試時機最佳實務：
- 重試 1：失敗後 24 小時
- 重試 2：失敗後 3 天
- 重試 3：失敗後 5 天
- 重試 4：失敗後 7 天（搭配催款郵件升級）
- 4 次重試後：強制取消並提供重新啟用路徑
智慧重試提示： 在原始付款成功的月份日期進行重試（如果之前 Day 1 成功，則在 Day 1 重試）。Stripe 智慧重試會自動處理此項。
催款郵件序列
| 郵件 | 時機 | 語氣 | 內容 |
|---|---|---|---|
| 1 | 第 0 天（失敗） | 友善提醒 | 「您的付款未成功。請更新您的卡片。」 |
| 2 | 第 3 天 | 協助提醒 | 「快速提醒 — 更新您的付款以保持使用權限。」 |
| 3 | 第 7 天 | 急迫感 | 「您的帳戶將在 3 天後暫停。請立即更新。」 |
| 4 | 第 10 天 | 最終警告 | 「最後機會，保持您的帳戶活躍。」 |
催款郵件最佳實務：
- 直接連結到付款更新頁面（如可能，無需登入）
- 顯示他們將失去什麼（資料、團隊存取權）
- 不要責怪（「您的付款失敗」而非「您未付款」）
- 包含支援聯絡方式
- 純文字郵件比設計精美的郵件效果更好
恢復基準
| 指標 | 差 | 平均 | 好 |
|---|---|---|---|
| 軟拒絕恢復率 | <40% | 50-60% | 70%+ |
| 硬拒絕恢復率 | <10% | 20-30% | 40%+ |
| 整體付款恢復率 | <30% | 40-50% | 60%+ |
| 預催款預防率 | 無 | 10-15% | 20-30% |
如需完整的催款手冊與供應商特定設定，請參閱 references/dunning-playbook.md。
指標與衡量
關鍵流失指標
| 指標 | 公式 | 目標 |
|---|---|---|
| 月流失率 | 流失客戶數 / 月初客戶數 | B2C <5%，B2B <2% |
| 營收流失（淨額） | （流失 MRR - 擴張 MRR）/ 期初 MRR | 負值（淨擴張） |
| 取消流程挽留率 | 挽留數 / 總取消會話數 | 25-35% |
| 優惠接受率 | 接受優惠數 / 顯示優惠數 | 15-25% |
| 暫停重新啟用率 | 重新啟用數 / 總暫停數 | 60-80% |
| 催款恢復率 | 恢復數 / 總付款失敗數 | 50-60% |
| 取消時間 | 從首次流失訊號到取消的天數 | 追蹤趨勢 |
同類群組分析
依以下維度區分流失：
- 獲取管道 — 哪些管道帶來更黏著的客戶？
- 方案類型 — 哪些方案流失最多？
- 使用期間 — 大多數取消發生在何時？（30、60、90 天？）
- 取消原因 — 哪些原因正在增加？
- 挽留優惠類型 — 哪些優惠對哪些群組最有效？
取消流程 A/B 測試
一次測試一個變數：
| 測試 | 假設 | 指標 |
|---|---|---|
| 折扣百分比（20% vs 30%） | 較高折扣挽留更多 | 挽留率、LTV 影響 |
| 暫停期間（1 個月 vs 3 個月） | 較長暫停提高回歸率 | 重新啟用率 |
| 調查位置（優惠前 vs 優惠後） | 先調查可個人化優惠 | 挽留率 |
| 優惠呈現方式（彈窗 vs 全頁） | 全頁獲得更多注意 | 挽留率 |
| 文案語氣（同理心 vs 直接） | 同理心減少摩擦 | 挽留率 |
如何執行取消流程實驗： 使用 ab-testing 技能設計統計嚴謹的測試。PostHog 非常適合取消流程實驗 — 其功能旗標可將使用者分流到不同流程，其漏斗分析可追蹤取消流程的每個步驟（調查 → 優惠 → 接受/拒絕 → 確認）。請參閱 PostHog 整合指南 進行設定。
常見錯誤
- 完全沒有取消流程 — 即時取消等於把錢留在桌上。即使簡單的調查 + 一個優惠也能挽救 10-15%
- 讓取消難以找到 — 隱藏取消按鈕會引發不滿與負評。許多司法管轄區要求簡便取消（FTC 點擊取消規則）
- 每個原因都給相同優惠 — 統一的折扣無法解決「缺少功能」或「使用不夠」
- 折扣太深 — 50% 以上的折扣會訓練客戶為了優惠而取消再回來
- 忽略非自願流失 — 通常佔總流失的 30-50%，且最容易解決
- 沒有催款郵件 — 讓付款失敗默默取消帳戶
- 罪惡感文案 — 「您確定要拋棄我們嗎？」會損害品牌信任
- 未追蹤挽留優惠的 LTV — 30 天後又流失的「被挽留」客戶其實並未被真正挽留
- 暫停太久 — 超過 3 個月的暫停很少重新啟用。設定限制。
- 沒有取消後路徑 — 讓重新啟用變得簡單，並觸發贏回郵件，因為有些流失的使用者會想回來
工具整合
如需實作，請參閱 工具註冊表。
留存平台
| 工具 | 最適合 | 關鍵功能 |
|---|---|---|
| Churnkey | 完整取消流程 + 催款 | AI 驅動的適應性優惠，平均挽留率 34% |
| ProsperStack | 附分析功能的取消流程 | 進階規則引擎，Stripe/Chargebee 整合 |
| Raaft | 簡單取消流程建構器 | 易於設定，適合早期階段 |
| Chargebee Retention | Chargebee 客戶 | 原生整合，前身為 Brightback |
帳務供應商（催款）
| 供應商 | 智慧重試 | 催款郵件 | 卡片更新服務 |
|---|---|---|---|
| Stripe | 內建（智慧重試） | 內建 | 自動 |
| Chargebee | 內建 | 內建 | 透過閘道 |
| Paddle | 內建 | 內建 | 託管 |
| Recurly | 內建 | 內建 | 內建 |
| Braintree | 手動設定 | 手動 | 透過閘道 |
相關 CLI 工具
| 工具 | 用途 |
|---|---|
stripe |
訂閱管理、催款設定、付款重試 |
customer-io |
催款郵件序列、留存活動 |
posthog |
透過功能旗標進行取消流程 A/B 測試、漏斗分析 |
mixpanel / ga4 |
使用追蹤、流失訊號分析 |
segment |
健康評分的事件路由 |
相關技能
- emails：用於取消後的贏回郵件序列
- paywalls：用於應用程式內的升級時刻與試用到期
- pricing：用於方案結構與年度折扣策略
- onboarding：用於激活以預防早期流失
- analytics：用於設定流失訊號事件
- ab-testing：用於以統計嚴謹性測試取消流程變體
