SaaS 流失預警自動偵測

🎯 這條流程解決什麼

訂閱制生意最痛的地方，是流失幾乎都有前兆，偏偏沒人即時看到。一個原本每天登入、天天用核心功能的帳號，會先變成三天登入一次、再變成兩週沒上線，最後在續約日按下「取消訂閱」。這些訊號全都藏在後台的事件數據裡，而客戶成功團隊每天忙著回工單、接電話，根本沒有餘力一個帳號一個帳號去翻使用紀錄。

純人工要做這件事到底要花多少時間？以一個管 300 個付費帳號的 CS 來說，光是每週手動拉一次 Mixpanel 報表、比對哪些帳號使用量掉了、再交叉核對 HubSpot 看是哪一階方案，大概要花掉一個人 6 到 8 小時，而且只能做到「每週一次」的粗略掃描。等於說，一個帳號從開始冷掉到被發現，中間平均隔了 5 到 10 天，這段時間正是挽留的黃金期，卻完全被浪費掉。更現實的是，多數團隊根本沒做這件事，就是被動等系統寄退訂通知，看到的時候帳已經退了。

換算成本，一個月流失 5 個年約客戶、每個年費 36,000 元，等於一年憑空蒸發 180 萬營收，這還沒算上重新獲客的行銷成本。流失預警不是「錦上添花」的分析報表，而是直接和經常性收入掛鉤的防線。

導入後的改變

導入前：CS 被動等退訂通知，看到時帳號已經取消；想主動經營也不知道該先打給誰，只能憑印象或等客戶自己抱怨；每週手動拉報表 6 到 8 小時，覆蓋率還只有重點大客。

導入後：每天清晨系統自動跑完所有帳號的健康分數，紅色高風險清單直接推到 CS 的 Slack，名字、風險原因、上次登入時間一目了然；黃色帳號不用人管，系統自己推再啟用內容。CS 從「不知道該追誰」變成「打開 Slack 就知道今天該關懷哪五個帳號」。

合理的效益估算：把流失偵測從「每週一次、延遲 5 到 10 天」變成「每天一次、延遲不到 24 小時」，挽留介入時間平均提早一週以上。實務上，能在用戶真正冷掉前就接觸到的高風險帳號，挽留成功率通常比退訂後再贏回高出 2 到 3 倍。以前述每月流失 5 個年約客為例，只要靠預警多救回其中 2 個，一年就守住 72 萬營收，CS 每週還省下 6 小時以上的手動拉表時間，可以拿去做真正的客戶關懷。

流程怎麼運作

這條流程在 n8n 或 Make 上用每日排程觸發，對應 frontmatter 的五個節點：

1. 行為彙整（📈）：排程每天清晨從 Mixpanel（或你的事件分析工具）抓出每個帳號的關鍵行為——登入頻率、核心功能使用次數、距上次登入的間隔天數、活躍席次數變化等。這一步是整條流程的地基，抓的指標要對應你產品「真正代表價值」的動作，而不是只看有沒有登入。

2. 健康評分（🧮）：把彙整來的行為數據丟進評分邏輯，依「使用量下滑幅度」與「停用天數」算出每個帳號的健康分數。最簡單可用加權公式（例如核心功能週使用次數佔 50%、登入間隔佔 30%、席次活躍率佔 20%），進階一點可以比對該帳號自己的歷史基準，看是「相對於過去掉了多少」而非絕對值。

3. 風險分級（🚦）：依分數切成綠／黃／紅三級。綠色維持觀察、黃色進自動挽留、紅色進人工介入。門檻要定期回測校正，初期建議寧可把線拉嚴一點，讓紅色名單精準，避免 CS 對著一堆假警報疲乏。

4. 自動挽留（✉️）：黃色帳號透過 HubSpot 自動推送再啟用內容——例如「你還沒試過某個功能」的功能提示信、使用技巧、成功案例，把人輕量地拉回來，不耗 CS 人力。

5. CS 介入（🔔）：紅色帳號立刻把卡片推到 Slack 通知對應 CS 專員，附上帳號名、風險原因與聯絡窗口；CS 人工關懷後把處理結果與後續狀態回寫到 HubSpot，形成閉環，方便日後檢討哪種介入有效。

需要的工具與串接重點

• 平台（n8n / Make）：負責排程與串接編排。建議設定為每日固定時段（如台灣時間早上 8 點）跑，讓 CS 一上班就拿到當天名單。資料量大時記得分批處理、加上 API 速率限制的等待節點，避免一次打爆 Mixpanel API。
• Mixpanel：行為數據來源。需先在產品端把核心事件埋好（登入、關鍵功能觸發），健康分數的品質完全取決於這層事件設計是否到位。
• HubSpot：帳號主檔與自動挽留信的執行端，同時是處理結果的回寫去處，把行為分數寫回成自訂屬性，業務與 CS 都能在同一個畫面看到。
• Slack：紅色名單的即時通知管道，建議獨立開一個 churn-alert 頻道，並把回寫按鈕做成互動訊息，CS 點一下就能標記「已聯繫」。

串接重點是「帳號 ID 對齊」：Mixpanel、HubSpot 兩邊一定要有共同的唯一識別碼（通常是帳號的內部 ID 或公司網域），否則分數算出來對不上人。可以先用 /automation 上的串接概念把資料管線理清楚再開始。

常見錯誤與注意事項

• 資料隱私要先過關：健康分數會大量讀取用戶使用行為，務必確認資料蒐集範圍符合隱私規範與用戶同意範圍，分數結果僅供內部留存運用，不可外洩給用戶本人以外的第三方，也不要在對外信件裡暴露「你被標為高流失風險」這種會嚇跑客戶的措辭。
• 財務讓利不可全自動：任何「自動給折扣、自動延長方案」等涉及財務的挽留手段，一律先進人工確認再執行，AI 不取代營收決策，不讓系統自行決定讓利幅度，否則容易被有心人摸清規則、或誤發造成損失。
• 避免假警報疲乏：門檻沒校正好會讓紅色名單塞滿其實沒事的帳號，CS 久了就不看了。上線後前兩週要每天人工回看名單準不準，再微調權重。
• B2B 要看「席次層級」：企業客戶不能只看單一登入者，要看整個團隊的活躍度，一個關鍵管理員離職可能就是大流失前兆，這類訊號要特別納入評分。

台灣中小企業情境案例

台中一家做電商出貨管理 SaaS 的團隊，付費客戶約 280 家中小型賣家，月費方案為主。過去他們完全是被動的：Stripe 寄來退訂通知才知道又掉一家，CS 三個人每天忙著接「為什麼運費算錯」的工單，根本沒空看誰快流失。一個季度下來月流失率常在 5% 上下徘徊。

導入這條流程後，他們把「每天有沒有匯入訂單」「有沒有列印出貨單」設為核心事件，每天早上紅色名單直接進 Slack。第一週就抓到 6 家連續 10 天沒匯訂單的賣家，CS 一通電話打過去，才發現其中 4 家是換了配合的物流、卡在串接設定不會用，根本不是不想用。CS 協助重設後全數留存。三個月後，他們的月流失率從 5% 降到約 3.2%，等於每月少掉 5 家退訂，CS 也從「救火」轉成「主動關懷」，客戶滿意度跟著上來。

延伸應用

這條流程的底層是「行為數據 → 分數 → 分級觸發」，換個分數定義就能變出很多用途：把分數反過來看「成長潛力」，就能自動標出最適合推升級方案的帳號，餵給業務做向上銷售；把停用天數門檻拉長，可以串接 /workflows 的贏回流程，讓已流失帳號自動進入再行銷名單；也可以把健康分數做成主管的週報儀表板，一眼看出整體留存趨勢。更進階的玩法是把這套預警和 /recipes 的挽留內容食譜結合，讓不同風險原因（例如「沒用到某功能」vs「使用量整體下滑」）自動配對不同的挽留文案，做到真正的個人化留存經營。

流程圖

用到的工具

更多「專業服務」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →