churn-prevention

churn-prevention 技能總覽

churn-prevention 技能可協助 AI 代理設計實際可執行的 SaaS 留存流程，特別適合處理取消訂閱流程、挽留優惠、扣款失敗補救，以及取消後追蹤等情境。它最適合創辦人、成長負責人、生命週期行銷人員、帳務／計費負責人，以及 Customer Success 團隊；如果你的需求不是泛泛地腦力激盪留存點子，而是要拿到一份可落地的降 churn 操作方案，這個技能會更有價值。

churn-prevention 技能適用於什麼情境

當真正要解決的問題，是修補 churn 真正發生的關鍵節點、留住更多訂閱用戶時，就該使用 churn-prevention：

• 取消流程太弱、太突兀
• 沒有 exit survey，或調查資料無法使用
• 所有用戶都套用同一種挽留優惠
• failed payment recovery 有明顯缺口
• 沒有針對高價值帳戶的分流處理
• 沒有 health score 或主動留存機制

這個技能很適合訂閱型產品、SaaS、會員制服務，以及其他以經常性收入為主的商業模式。

哪些人適合安裝它

如果你的工作內容包含以下項目，這個 churn-prevention 技能會特別實用：

• self-serve SaaS 留存優化
• B2B 或 team plan 的取消處理
• 透過 dunning 降低 involuntary churn
• 針對高風險帳戶設計 Customer Success playbook
• 將留存策略結合 billing 與產品使用訊號

如果你的目標明確是寫取消後的 email，鄰近的 email-sequence 技能可能更直接。若你的目標是提升升級轉換，而不是留存，這也不是最優先該裝的技能。

它和一般 prompt 有什麼不同

一般 prompt 往往只會給出像「改善 onboarding」或「提供折扣」這類寬泛建議。這個技能更偏向營運與執行面。從 repository 的內容可以看出，它會引導模型優先做到以下幾件事：

• 先確認是否已有產品／市場定位相關脈絡
• 區分 voluntary churn 與 involuntary churn
• 建立有明確階段的取消流程
• 將取消原因對應到動態挽留優惠
• 提供具體的 dunning timeline，而不是模糊的付款提醒
• 以實作優先順序為主，而不是丟一堆戰術清單

正是這種結構，讓 churn-prevention 真正適合執行層面使用。

多數使用者最先在意的問題

在安裝前，多數團隊最想知道的是：這個技能能不能幫忙回答像以下這類實際問題？

• 我們的取消流程到底應該怎麼設計？
• 哪些取消原因應該對應哪些挽留優惠？
• 怎麼降低 failed-payment churn，又不會惹惱用戶？
• 什麼情況該由 Customer Success 介入，而不是全自動處理？
• 在請模型產出方案前，我們需要先準備哪些輸入資訊？

在這些問題上，這個技能比單純快速瀏覽 repo 更有用，因為它不只提供 workflow prompt，還搭配了兩個很關鍵的參考檔案：references/cancel-flow-patterns.md 和 references/dunning-playbook.md。

如何使用 churn-prevention 技能

churn-prevention 的安裝與閱讀起點

請從 repository 安裝這個技能：

npx skills add https://github.com/coreyhaines31/marketingskills --skill churn-prevention

接著打開 skills/churn-prevention 目錄，優先閱讀以下檔案：

• SKILL.md
• references/cancel-flow-patterns.md
• references/dunning-playbook.md
• evals/evals.json

真正有判斷價值的核心在 references；而 evals 則能幫你看出，這個技能心目中的「好答案」應該包含哪些內容。

在下 prompt 前先讀這個檔案路徑

SKILL.md 明確寫到：在繼續向使用者提問前，要先檢查 .agents/product-marketing-context.md 或 .claude/product-marketing-context.md。這一點很重要，因為當模型先知道以下背景時，留存建議通常會準很多：

• positioning
• target customer
• use cases
• pricing
• competitors
• product packaging

如果略過這一步，你在使用 churn-prevention 時，很容易得到過度通用的優惠設計，以及偏弱的挽留邏輯。

churn-prevention 技能需要哪些輸入才會表現好

churn-prevention 技能在你提供一份精簡但可操作的營運快照時，效果最好；不要只丟一句「我們 churn 很高」。有用的輸入包括：

• monthly churn rate
• voluntary 與 involuntary churn 的占比
• active subscriber count
• average revenue per customer 或 MRR
• self-serve 還是 sales-assisted 模式
• billing provider 與 subscription platform
• 目前的 cancel flow
• failed payment rate 與主要失敗原因
• usage 或 health 指標
• 目前是否已有 save offers
• Customer Success 是否能介入高價值帳戶

即使只提供部分資訊，也足以開始；但只要模型知道你的 billing 架構與帳戶價值分層，輸出品質通常會明顯提升。

如何把模糊目標改寫成強而有力的 churn-prevention prompt

較弱的 prompt：

「Help reduce churn.」

較強的 prompt：

「Use the churn-prevention skill. We run a $49/mo B2B SaaS with 2,000 paying accounts. Monthly churn is 7%, roughly 5% voluntary and 2% involuntary. We use Stripe. Our current cancel flow is just confirm cancel. Failed payments are mostly expired cards. We have no save offers and no CS routing. Build a practical churn-prevention plan covering cancel flow stages, exit survey, save offers by cancellation reason, dunning timeline, and a 30/60/90 day rollout.」

這類 prompt 之所以效果更好，是因為它要求的輸出，正好就是這個技能被設計來產生的內容。

好的 churn-prevention 使用結果通常長什麼樣子

一份夠強的 churn-prevention 回應，通常會包含：

• 主要 churn 類型的診斷
• cancel-flow 結構
• 建議的 exit survey 類別
• 依具體原因動態對應的 save offers
• 針對 failed payments 的 dunning 建議
• 高價值客戶的帳戶分流邏輯
• 有優先順序的實作計畫

如果模型只給你一堆籠統的留存建議，通常代表它拿到的商業背景不夠，或沒有正確觸發這個技能的用法。

churn-prevention 很擅長的取消流程指引

這個技能的一大實用強項是 cancel-flow 設計。參考檔展示了一個典型模式：

Cancel button → Exit survey → Dynamic offer → Confirm → Post-cancel

它之所以實用，在於會依商業模式調整這個框架：

• B2C/self-serve：流程簡短、自動化、以單一主要優惠為主
• B2B/team plans：將較高 MRR 帳戶分流給 Customer Success
• enterprise 或 admin-led plans：更強調帳戶影響與人工接觸

因此，對於需要在自動化與人工介入之間拿捏的 Customer Success 團隊來說，churn-prevention 特別有參考價值。

churn-prevention 很擅長的 dunning 指引

references/dunning-playbook.md 提供了相當具體的 payment recovery 架構，包括：

• 卡片到期前的 pre-dunning
• smart retry timing
• 分階段 email reminders
• grace period 的處理方式
• 取消後如何銜接 win-back

如果 involuntary churn 在你的流失中占比不小，這會是你該用這個技能、而不是一般 prompt 的重要理由之一。這個 repository 的內容夠具體，足以產出可執行的 failed-payment recovery 方案。

Customer Success 與成長團隊最適合的 churn-prevention 工作流程

對 Customer Success 來說，一個實際可行的 churn-prevention 工作流程是：

1. 先整理 churn、billing 與 account tier 背景。
2. 要求模型先拆分 voluntary 與 involuntary churn。
3. 產出包含 survey 與 offer mapping 的 cancel-flow 草案。
4. 另外獨立產出 dunning 調整方案。
5. 檢查哪些節點應該由人工介入，而不是自動化。
6. 再把方案拆成各團隊可執行的 implementation tickets：product、lifecycle、billing、CS。

這樣拆開做，可以避免一次得到一份過度膨脹的回答，也更容易真正轉成營運流程。

哪些 repository 檔案最能提升判斷品質

如果你只能先讀一個輔助檔案，針對取消體驗決策，首選是 references/cancel-flow-patterns.md。如果 failed payments 是主要問題，下一個就讀 references/dunning-playbook.md。

而 evals/evals.json 則可當成快速理解「好的 churn-prevention 使用方式長什麼樣」的捷徑。裡面的 assertions，往往比只快速看標題，更能清楚透露這個技能真正想覆蓋哪些面向。

這些實務細節會直接影響輸出品質

有幾個 prompt 細節，會明顯改善結果：

• 指定 business type：self-serve、SMB、mid-market、enterprise
• 提供 Customer Success 介入的帳戶價值門檻
• 說明 mobile cancellation 是否常見
• 提到 plan architecture：downgrade、pause、annual、monthly
• 補充來自客服或問卷的已知取消原因
• 告訴模型你接下來 30 天內實際能上線什麼

這些資訊能讓 save offers 更貼近現實，也能減少那種只有「best practice」卻無法落地的填充內容。

churn-prevention 技能 FAQ

churn-prevention 只適用於 SaaS 嗎？

不是。churn-prevention 技能最自然的應用場景確實是 SaaS 與訂閱制，但它同樣能用在會員制服務或其他經常性收費服務，只要取消流程與 failed payment recovery 對業務有影響。對一次性購買型業務，它的幫助就相對有限。

這個 churn-prevention 技能適合新手嗎？

適合，但前提是你至少掌握基本資訊：pricing、billing stack、目前 churn 水位，以及誰負責 retention。它對實際營運人員的價值會高於完全新手，因為很多建議都需要跨 product、billing 與 Customer Success 才能執行。

它和直接問 ChatGPT 要 churn 點子有什麼不同？

這個 repository 提供的是可重複套用的結構：它會先要求正確背景、拆分 churn 類型、採用分階段 cancel-flow 模型，並納入 dunning 邏輯。如果你的團隊需要的是可反覆使用的 retention workflow，而不是一次性的 prompt，churn-prevention 會更值得安裝。

什麼情況下不該使用 churn-prevention？

如果你的主要問題是以下情況，就不該先從 churn-prevention 開始：

• trial-to-paid 轉換偏低
• 客戶甚至還沒訂閱前的 activation 很弱
• 你只想寫 win-back email sequence
• 你要優化的是 upgrade paywall

這些問題和留存有關，但這個技能的核心仍是訂閱留存與取消預防。

churn-prevention 會幫到 failed payments 嗎？

會，而且這正是它最強的用途之一。dunning 參考檔具體到足以幫你設計 retry timing、提醒節奏、grace period，以及卡片到期前的預防流程。

churn-prevention 對 Customer Success 團隊有幫助嗎？

有，尤其當高價值帳戶不適合走全自動取消流程、而需要人工接手時更是如此。這個技能可以幫你定義：什麼時候顯示優惠、什麼時候提供通話選項、以及何時應依帳戶價值或風險升級給 Customer Success。

如何改善 churn-prevention 技能的使用效果

提供分層後的 churn 資料給模型

想最快提升 churn-prevention 的結果，最有效的方法就是把以下資料拆開：

• voluntary churn
• involuntary churn
• plan-level churn
• 依客戶類型或帳戶規模區分的 segment-level churn

如果沒有做 segmentation，模型很容易把取消 UX 問題和 payment recovery 問題混在一起，結果兩邊都排不出正確優先順序。

提供真實取消原因，不要只靠猜測

如果你手上有 exit survey 資料、support tags、通話紀錄，或 cancellation transcripts，請整理成一段簡短摘要一起提供。這會幫助技能產生更貼近真實異議的 offers，而不是預設對所有人都丟折扣。

例如，「too expensive」、「missing feature」和「temporary pause in need」就不應該走同一條挽留路徑。

用限制條件強化 churn-prevention prompt

直接告訴模型你目前做不到的事，例如：

• 這個月沒有 engineering support
• 不能更換 billing provider
• 沒有 Customer Success headcount
• discounting 空間有限
• 目前只能用 email 和 in-app

這些限制會迫使模型提出更可執行的建議，也能避免產出看起來完整、實際卻不能用的方案。

留意 churn-prevention 常見失敗模式

在使用 churn-prevention 時，最常見的弱輸出包括：

• 把所有 churn 當成同一個問題處理
• 在單一 cancel flow 裡塞太多 offers
• 忽略 billing provider 的限制
• 過度依賴折扣，明明 downgrade 或 pause 更合適
• 忘記 post-cancel communication 與 win-back
• 跳過 implementation priority

如果你看到這些情況，應要求模型依 churn 類型與 business model 重新修訂方案。

要求依取消原因做 offer mapping

一個高價值的迭代 prompt 是：

「Revise this churn-prevention plan into a table with cancellation reason, best save offer, fallback option, and when to route to Customer Success.」

這種格式很容易快速暴露邏輯缺口，也更方便拿去跟利害關係人一起 review。

用分層迭代，不要一次丟一個超大 prompt

通常分 3 輪做，效果會更好：

1. 診斷 churn 來源
2. 設計 cancel flow 與 dunning 邏輯
3. 把建議轉成 rollout steps 與 success metrics

這種分層工作法能提升準確度，也讓 churn-prevention 更容易被真實團隊採用。

對照 repository references 做驗證

在採用任何輸出前，先拿它和以下檔案比對：

• references/cancel-flow-patterns.md
• references/dunning-playbook.md

這是最簡單的品質檢查方式。如果答案漏掉了這些檔案中的核心階段，通常代表你的 prompt 還需要更多背景，或應縮小範圍。

不只要策略，也要要求 implementation priority

當你要求模型進一步排出順序時，這個技能就會實用很多，例如：

• 最高影響的 quick wins
• 各團隊依賴關係
• 哪些項目不靠 engineering 也能先上
• 什麼應該優先測試
• 用哪個 metric 定義成功

這能把 churn-prevention 從策略建議，真正推進成執行計畫。

初稿後要補上衡量方式

模型給出方案後，接著要它列出評估成效所需的 KPI，例如：

• 各取消原因的 save rate
• 各 offer 類型的 accept rate
• dunning 帶回的 recovered revenue
• churn 中 involuntary churn 的比例
• 不同客群區段的 retention impact

好的 churn-prevention 實作不只是把流程設計出來，更重要的是證明哪些調整最有效率地降低 churn。