當使用者想要降低流失率、建立取消流程、設定挽留優惠、處理付款失敗或實施留存策略時使用。也適用於使用者提及「流失」、「取消流程」、「離職流程」、「挽留優惠」、「催款」、「付款失敗恢復」、「贏回」、「留存」、「離職調查」、「暫停訂閱」、「非自願流失」、「一直有人取消」、「流失率太高」、「如何留住使用者」或「客戶一直在離開」。每當有人正在流失訂閱者或想要建立系統來預防時使用。對於取消後的贏回郵件序列，請參閱 emails。對於應用程式內的升級付費牆，請參閱 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：用於以統計嚴謹性測試取消流程變體
