客戶取消服務流程圖（由申請到帳戶關閉）
客戶取消服務流程圖：合約條款與通知期、在挽留之前先登記原因、方案階梯及其上限、最終帳單、資料匯出、收回存取權與流失代碼。
運作方式
把泳道改成你們真實的團隊
把客戶、挽留小組、挽留經理、帳務、服務營運與收益營運，換成你們真正擁有的職能。規模較小的機構通常把挽留小組併入客戶支援，並把經理那條泳道交給背負收益指標的人；自助式產品可能根本沒有挽留小組，那麼方案階梯就變成取消流程裡的幾個畫面。寧可合併一條泳道，也不要留一條空泳道。但客戶那條泳道請保留原樣：它承載兩個方框——提出申請，以及對方案的回覆——而在那之後的一切，都是發生在帳戶身上，而不是與客戶一起發生的。
先寫好原因分類表，再去碰方案
「按原因分類表登記原因」在清單存在、而且短到可以選得出來之前，是沒有價值的。八到十二個代碼通常已經足夠：價錢、缺少功能、服務或穩定性差、使用率低、預算被砍、專案或合約結束、改為自行開發、轉用某個具名的競爭對手、公司結業或被收購。另外加一個自由填寫欄位，並要求代碼填妥之後個案才可以往下走。然後決定由誰、多久檢視一次分佈，因為沒有人回頭讀的分類表，會慢慢漂移到下拉選單中第一個選項那裡去。
建好方案階梯，並為它加一個上限
按對你們的成本高低排出級數，而不是按感覺：先是暫停或降級方案，然後是以較低價格延長合約期，再是服務點數或加大範圍，最後才是直接減價。在「讓步是否在小組授權之內？」旁邊，把小組的上限寫成年度價值的百分比和一個最長期限，並寫明每一級之上由誰批准。把令「是否容許嘗試挽留？」得出「不容許」的排除情況記下來，然後按原因代碼量度每一級實際留住了甚麼，令這道階梯的次序由證據決定，而不是由小組最容易給出去的那項讓步決定。
定好通知規則與生效日期
決定通知期由甚麼開始計算——收到取消意向的日期，而不是個案被開立的日期——以及這段期間是按曆月計算，還是計到下一個扣款日。寫明在自動續期的截止日之後才發出通知會怎樣處理，因為那正是產生爭議的情況。然後定死「以書面確認通知期與生效日期」的內容：各項日期、關閉之前的服務水平、預計的最終金額、資料匯出的途徑，以及刪除日期。你們市場的消費者取消權可能凌駕於較長的合約通知期之上，請先核對。
訂好收回存取權與資料保留的時限
把「收回存取權並訂定刪除日期」變成一份清單，涵蓋用戶帳號、API 金鑰與權杖、系統整合、單一登入的指派、共用內容、郵寄名單，以及隨服務發出的任何硬件或授權。決定關閉之後保留甚麼、依據甚麼合法理由保留、保留多久——帳務紀錄通常因稅務原因會比帳戶活得更久，個人資料則不應如此——並把清除排入排程，而不是留給幾個月之後的一次人手決定。寫明由誰確認已經做妥，以及那份確認記錄在哪裡。
議定流失的定義，然後走一次並發佈
在任何人動手建報表之前，先定好主動流失與被動流失如何計算、一宗取消歸屬於哪一個日期，以及降級或暫停如何處理。寫下「是否適合日後贏回？」背後的封鎖規則，以及再次接觸一位前客戶之前的最短靜默期。然後帶著定稿的圖，與一位挽留人員、一位帳務同事和負責帳戶開通的人一起走一次，按他們實際的做法而不是政策寫的做法改正，再發佈該版本並保留此前的版本，令日後打開它的人知道自己看的是哪一版。
常見問題
客戶取消服務流程包含哪些步驟？
不論取消申請由哪一個渠道進來都要接收，並帶時間戳登記；調出合約，確認最短合約期、通知期與自動續期日期；在提出任何方案之前，按一份固定的分類表登記原因；判斷是否根本容許嘗試挽留；由挽留方案階梯提出一次方案，讓步超出小組授權的就交由經理批核；然後要麼實施議定的變更並訂下回訪日期，要麼以書面確認通知期與生效日期；計算並結清最終帳單，結果是按比例退款、提前終止費用，或者甚麼都不欠；在生效日期之前保留存取權，並讓資料匯出保持可用；到期才收回存取權，而不是在申請當日收回，同時訂定刪除日期；發出離開問卷；在 CRM 中登記流失代碼並匯報；最後決定該帳戶是適合日後贏回，還是應該停止一切聯絡。次序比清單本身更重要：在提出方案之前先登記原因、在收回存取權之前先確認生效日期，正是令這個流程不會出事的兩件事。
本頁與客戶退款流程圖有甚麼不同？
退款流程結清的是一筆款項。它問這宗申請是否落在退款政策與期限之內、經理是否會批准一筆通融、原始付款是否已經結算而且未曾退過款，以及是否有一宗拒付正在並行處理——它在款項回到客戶手上的那一刻結束，那是 /yue/templates/客戶退款流程 上的客戶退款流程圖所覆蓋的地面。取消服務流程結束的是一段關係，而金錢只是其中一條腿。本圖處理的是合約通知期、最短合約期與自動續期、挽留方案以及誰有權批准、生效日期、收回存取權、資料匯出與刪除、離開問卷，以及流失如何登記代碼與匯報。兩者只在一個點相遇：「生效日期的款項如何結算？」可能得出應退款，而執行退款屬於退款流程的工作。如果你們要決定是否就一筆交易退錢，請用退款範本；如果你們要結束一項訂閱或一份合約，請用這一份，並讓它在那一個步驟上呼叫退款流程圖。
是否應該向每一位取消的客戶提出挽留方案？
不應該，而本圖把這個問題放在方案之前，而不是之後。「是否容許嘗試挽留？」排除了幾類情況：已經在上一次取消時接受過挽留方案的帳戶、明確表示不想再被推銷的客戶、正處於未了結帳務或服務爭議的帳戶（在那裡一個折扣會被讀成一種和解），以及公司已經結業、被收購或預算被完全砍掉的情況。向這些個案提出方案，既浪費小組的時間，也惹惱了早已作出決定的人。「一次為限」規則背後的商業理由更簡單：單靠價錢留住的客戶，往往在下一個合約期又回到同一場對話，只是起點變成了那個較低的數字，所以一盤生意如果每一次取消都減價，它留住的不是收益，而是在逐個帳戶地為自己的價目表重新定價。按原因代碼匯報挽留成功率與平均讓步幅度，這個模式很快就會顯現出來。
已取消的客戶應該在甚麼時候失去服務存取權？
在生效日期，也就是已付費期間的結束日或合約通知期的結束日，而不是提出申請的當日。本圖把這一點畫成一個決策「是否已到生效日期？」，後面掛著一個等待循環，在日期到來之前讓帳戶保持生效、讓資料匯出保持可用。提早切斷存取權是這個流程裡最常見的失誤，而且它的代價與所省下的東西完全不成比例：客戶已經為這段時間付過錢，通常還需要把資料取出來，於是一次安靜的離開變成一張工單、一宗拒付或者一則公開評價。例外情況很窄，而且應該分開寫明——催繳已經走完全程仍然欠費、違反服務條款，或者欺詐——並且應該由有權作這個判斷的人決定，而不是由處理這宗取消的人順手決定。
主動流失與被動流失有甚麼分別？
主動流失是客戶決定離開。被動流失是帳戶因為一次付款失敗、而款項始終沒有收回而關閉——信用卡過期或換卡、交易被拒、授權書失效，又或者一張發票在對方的採購到付款系統裡不見了。它們在單一的流失數字裡看起來一模一樣，底下卻毫無共通之處。主動流失要用產品、服務與定價來回答；被動流失要用付款方面的管道功夫來回答，例如卡號自動更新、更好的重試時機，以及真的有人會讀的催繳訊息，而其中可以收回的比例高得令人意外。這正是本圖在受理階段以「主動取消還是欠費？」把兩者分開、並給欠費路徑一個自己的催繳與暫停服務循環的原因——那條路徑最後要麼以帳戶恢復、不計入流失作結，要麼匯入同一條通知與退出處理的主幹。在 CRM 裡分開登記代碼、分開匯報，否則可以收回的那一半，會一直藏在平均數裡面。