概念地圖・顧客成功階梯
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：行銷
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
顧客成功階梯：每一階都要有使用證據
維修窗口把滅菌鍋管理平台的帳號全開好了，客戶下一次報修仍把照片印出來夾在保養單裡。交付清單打完勾，資料交接還停在紙本——這時需要看客戶成功到了哪一步。顧客成功階梯把導入、採用、擴張與倡議畫成四階，逐一核對客戶完成了什麼工作、誰在持續使用、使用範圍有沒有增加。本文依實務整理這張操作圖；階高只為了辨識階段，沒有通用的分數或天數門檻。
階梯上的四種證據
這四階是本文的操作型整理。Winning by Design 的實務模型區分導入、採用與擴張，強調持續產生成果；GitLab 的客戶成功手冊則把採用、可衡量成果與客戶倡議列入工作。本文把這些實務觀念組成便於現場核對的階梯，沒有單一學術原典規定所有客戶必須依序走完。
| 階段 | 要留下的客戶端證據 | 容易誤認的訊號 |
|---|---|---|
| 導入 | 客戶首次完成原先要做的工作，確認結果有用 | 帳號開通、資料匯入、教學結束 |
| 採用 | 同類工作再次出現時，客戶能持續透過平台完成 | 登入次數很多，工作都由服務人員代做 |
| 擴張 | 新增職務、團隊或任務範圍，且實際取得成果 | 先加開帳號，使用範圍仍留在原處 |
| 倡議 | 客戶自願向他人推薦，能說明自己得到的幫助 | 禮貌稱讚、被要求轉貼、靠獎勵填推薦表 |
一個客戶可以持續使用原有功能，同時向同行推薦；新增使用範圍也可能完全沒有加購。把倡議另外做記號，連同任務、職務與觀察日期保存——階梯協助分配支援，單一的「最高階段」會丟掉這些細節。
客戶進階要經得起現場核對
一、先把原先的工作寫回來。滅菌鍋維護窗口想解決的事，可能是接電話時立即找到上次維修紀錄，方便交給負責人。首次成果就要落在這個交接上。若教學只演示照片上傳，還得接著看資料有沒有被找出、被接手——功能示範結束，任務仍有後半段。自問：客戶原先想完成的工作是什麼？
二、把操作人的職務記進去。平台有一筆新紀錄時，查明是客戶的維護窗口登錄，還是供應商客服接到訊息後補登。兩種紀錄都有服務價值，對採用的判斷卻需要分開保存。共用帳號尤其容易混在一起，訪談時請當班窗口把上次的操作重走一遍——滑鼠交到誰手上，常比報表更快揭曉。自問：這個行為由誰實際完成？
三、跟到下一次工作出現。維護紀錄不會每天都更新。觀察期間應跟著客戶原有的交接節奏安排：下一次需要找資料時，是否仍會打開平台、找到正確內容並交出去？保留任務發生的時間與結果，避免把一次陪同教學直接標成採用——真正的檢驗點，是工作再來的那一天。自問：成果持續出現，還是只完成了一次示範？
四、讓退階有接手的人。客戶窗口異動，原本共同登錄的兩個職務剩下一個；也可能維護責任集中後，只需要查閱、不再需要跨窗口共編。更新目前範圍，再決定補哪段導入。支援工單要寫接手人與下一次核對任務——退階應該觸發處理，不能只在儀表板換顏色。自問：需求縮小或使用中斷時，如何退階並重新支援？
滅菌鍋維護平台的使用紀錄，走一遍
底下這家台灣中部的滅菌鍋維護服務商，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實公司。場景聚焦平台的資料交接；設備操作仍依既有專業程序進行。
- 導入：找回一件維修紀錄。服務商陪客戶的維護窗口用平台找到前次維修單，窗口確認這正是本次交接需要的資料。記錄職務、要找的內容與查找結果；若仍靠客服從電腦調檔寄來，平台上的首次成果就繼續待核對。第一個成果要有客戶確認。
- 採用：自己持續登錄與查找。下一回交接發生，客戶窗口自行登錄新紀錄，另一回需要資料時也能自行取用。服務商把每次任務的完成者與結果留下來，確認日常工作接得上——帳號活躍的背後，要看得見誰把工作做完。代登留下的次數會讓採用看起來太漂亮。
- 擴張：另一個工作窗口加入。原先只有維護窗口使用，現在客戶端負責排程的同事也透過平台讀取共享紀錄，並完成自己的資料交接。新增的證據是職務與任務範圍；帳單金額可以維持原樣。多人共享，須有新增任務真的接住資料。
- 倡議：自願介紹給同行。客戶因為少了反覆翻找紀錄的麻煩，主動向同行介紹平台。記錄推薦對象與客戶提到的具體幫助。這件事也可能在原有窗口持續採用時就發生——所以圖上留了直接通往倡議的虛線。推薦可以早到，使用範圍照實記。
這段演練最值得留住的是每次交接的完成者。同樣一份維修紀錄，客服代查、客戶自己取用、另一個職務接著使用，各留下不同證據。把客戶名稱、職務、任務、完成者與結果放在同一筆紀錄裡，後續支援才找得到落點。若窗口離職，新人重新需要教學，就先補回首次成果；原先的歷史紀錄照樣保留，當前狀態另外更新。每家客戶的任務頻率不同，觀察期要共同約定，沒有一套通用天數或固定門檻。以上為說明結構用的示意情境，僅供理解框架之用。
成功階梯什麼時候會騙你
- 把倡議當成擴張的必然下一站。只用一小段功能的客戶，也可能很願意推薦；已經跨部門使用的客戶，可能因內部政策而不公開發言。若規定先加購才算倡議，就會漏掉第一種客戶。把推薦行為與使用範圍分開記——階梯的高度沒有替口碑排出資格順序。
- 登入量掩蓋了誰在代操作。維護服務商為了把事情做好，可能每次都替客戶上傳、補欄位、找附件。後台越熱鬧，團隊越容易誤以為客戶熟練。抽查最近一次真實任務，問清楚開始到結束各由誰完成，也把代操作的工時記下——那是尚待交接的工作量。
- 客戶走得高，生意仍可能吃力。客戶願意推薦、使用範圍增加，仍可能延後續約，或需要昂貴的人工協助。階段紀錄應與續約結果、服務成本和收入並排看。它沒有把成本扣完，更沒有替下一期預算簽字——商業成功要另外算，才知道這份成果能持續多久。
用痛點的眼光量首次成果
帳號開通，先留下的是供應商做完工作的痕跡。
每跨一階，都要再找客戶端的新證據。《痛點》的 P.A.I.N. 視角讓人把目光拉回具體的受苦時刻：報修電話響起，窗口要在一疊單子裡翻出誰處理過、資料又寄到哪裡。這張圖畫得出成果出現的階段，畫不出找不到紀錄時那個人的焦急。因此首次成果最好貼著客戶當時要完成的交接，接著問那次少了哪段麻煩、留下了多少額外整理工作。若每次上傳都要重新編檔名，平台帶來的順暢可能仍靠窗口加班維持——那段負擔也得進支援紀錄。今晚挑一位剛完成導入的客戶，請他描述最近一次自己找資料的過程，把中途需要求助的地方記給明天接手的人。
顧客成功階梯，常被問到的幾件事
顧客成功階梯一定要照四階順序走嗎？
這四階是本文用來安排觀察與支援的實務整理，適合先建立共同語言。實際記錄可以同時存在：客戶持續採用原有功能，也自願推薦給同行；另一些職務仍在導入。保留各項行為及其發生日期，需要分配支援時再看當前卡點——不要只剩一個最高階標籤。
怎麼判斷已經採用，要登入幾次才算？
先選定客戶反覆要做的任務，再依任務頻率約定觀察期間。每次核對完成者、結果與所需協助，確認客戶能持續取得預期成果。維修資料查找可能隔一段時間才發生，直接套用每日登入門檻會失真；自動登入或客服代操作也要另外標記——次數必須放回工作內容裡讀。
擴張一定代表加購，退階就代表快流失了嗎？
本文的擴張指使用範圍增加，包含新增任務、職務或團隊；是否帶來加購另記。退階則要查原因，窗口交接、工作整併與需求縮小各需不同處理。補導入、調整共同目標或縮減服務，都可以是合理下一步。續約風險仍需搭配預算、付款與客戶意願判斷。
續用的證據累積到同一批客戶身上，就能交給世代留存曲線追蹤；新增入口的人數則放回海盜指標。前者看同批客戶的留存變化，後者整理成長流程的整體指標。把本週新增的使用紀錄接上去，下次討論客戶進度，就從那件實際完成的工作開始。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。