銷售線索資格評定流程圖：由 MQL 到銷售已接納線索

甚麼是銷售線索資格評定流程圖：由 mql 到銷售已接納線索流程

線索資格評定是「製造興趣」與「投入銷售時間」之間的那道篩選。它由一條線索被取得開始——來自表格、活動名單、夥伴轉介或外撥名單——並終止於兩處之一：一個客戶經理已經接納的商機，或一條帶著原因代碼關閉的線索。它被刻意設計成一個兩端界線都很硬的短流程。

在這兩端界線之外，各有一個相鄰流程接手。上游的需求開發決定哪些推廣活動、名單與渠道會產生線索；本圖由那之後開始，此時線索已經在手。下游的商機管道負責由方案配合、建議書，到定價、談判與成交的全部環節；那是另一張圖，有另一套階段關口。如果你們要記錄的是一宗交易如何贏回來，那要用管道那張圖。如果你們要記錄的是一條線索如何贏得銷售人員的注意力，那就是這一張。

這個範本橫跨五條泳道——線索來源、市場部、SDR、客戶經理與銷售經理——以及五個階段：取得、市場資格評定、接觸、需求探詢與交接。六個決策承載了整套分流。市場部回答「是否達到 MQL 門檻？」。SDR 在執行接觸節奏時回答「是否收到回覆？」，並在需求探詢會議之後回答「是否符合資格評定準則？」。客戶經理回答是否接納這次交接，而當交接被退回時，由銷售經理裁決。夾在中間的是多數流程會略去的那個步驟：每一條出口——包括接觸節奏用盡後的「無回覆」——都要先經過「記錄淘汰原因代碼」，流程才決定把線索退回培育還是關閉它。這樣一來，線索品質就可以用數量來討論，而不是靠印象。

本流程圖涵蓋的內容

本範本包含

• 五條泳道（線索來源、市場部、SDR、客戶經理、銷售經理）橫跨五個階段：取得、市場資格評定、接觸、需求探詢與交接。
• 在任何評分之前的取得與資料補全：線索紀錄在 CRM 中建立，然後補全資料，並與既有客戶和進行中的商機做去重，避免兩個銷售人員同時在做同一家公司。
• 對照理想客戶輪廓配合度評分，其後是「是否達到 MQL 門檻？」——「是」把線索分派給一位 SDR，「否」把它留在培育中，而重新活躍會把它送回去重新評分，而不是任由它過期。
• 一段帶三向決策「是否收到回覆？」的接觸節奏：「是」預約需求探詢會議，「仍有接觸次數」折返到下一次接觸，而「無回覆」在節奏用盡後經原因代碼把線索送出流程。
• 一次需求探詢會議、按具名框架（BANT 或 MEDDIC）記錄的資格評定筆記，以及「是否符合資格評定準則？」——通過的線索發起一次銷售已接納交接，其餘的走原因代碼路徑。
• 兩個誠實的出口：「退回培育還是淘汰？」要麼把線索送回培育，要麼以淘汰關閉它；而被客戶經理退回的交接會送到銷售經理那裡，由他維持退回，或推翻退回、把它轉成一個已接納的商機。

何時使用本範本

• 市場部與銷售部對線索品質各執一詞，你們需要先就 MQL、銷售已接納與淘汰的定義取得共識，數字才開始有意義
• 你們正在 CRM 中設定線索狀態、分派規則或由線索到商機的轉換，希望在它被寫進欄位與自動化之前，先把目標流程定下來
• 線索在佇列裡變陳舊，你們需要看清它們卡在哪裡：MQL 門檻處、一段沒走完的接觸節奏裡，還是一次無人認領的交接上
• 你們正在培訓新的 SDR，希望用一頁說清接觸節奏、一次需求探詢會議必須產出甚麼，以及一條線索在甚麼時候可以退回培育
• 你們正在建立市場部與銷售部之間的服務水平協議，需要一張圖來說明這份協議所適用的那次交接

運作方式

1. 把泳道改成你們真實的角色

   把「線索來源」換成你們實際取得線索的那些來源，並把「SDR」改名為 BDR、內銷團隊，或你們團隊實際的叫法。如果同一個人既做開拓又做成交，可以把 SDR 與客戶經理兩條泳道合併——但要保留「客戶經理是否接納？」這個決策：交給自己的交接同樣需要一次明確的接納，否則就永遠不會有任何東西被正式拒絕。

2. 把 MQL 門檻寫下來

   只有當門檻落在紙面上，「是否達到 MQL 門檻？」才是一個真正的決策。寫明配合屬性（行業、規模、地區、地域、技術組合）、哪些行為計入、甚麼分數或規則觸發門檻、誰擁有它，以及多久覆核一次。在那之前，答案只是某個人的主觀判斷，而它不會保持一致。

3. 定義接觸節奏，以及甚麼令它結束

   訂定接觸次數、渠道、彼此之間相隔的工作日，以及第一次接觸由誰負責。這會把「仍有接觸次數」這個迴路由一種習慣變成一條規則，也給了「無回覆」一個確定的觸發條件，令線索離開佇列，而不是在裡面變陳舊。

4. 選定一個資格評定框架，並把它做成欄位

   決定「記錄資格評定筆記」捕捉的是 BANT（預算、決策權、需求、時機）還是 MEDDIC（量化指標、經濟決策人、決策準則、決策流程、已識別的痛點、內部支持者），然後把它們建成 CRM 欄位，而不是一個備註框。一個你無法據以出報表的框架，是一份清單，而不是一道關口。

5. 議定接納準則與退回路徑

   寫下客戶經理可以基於甚麼理由拒絕一次交接、最遲必須在甚麼時候回覆，並確認由誰裁決。這個範本把被退回的交接送到銷售經理那裡：他要麼維持退回，令線索走上原因代碼路徑，要麼推翻退回，把它轉成一個已接納的商機。如果這條路徑沒有定義，被退回的線索就會徹底停止流動。

6. 公佈原因代碼，並定期覆核

   固定一份簡短的封閉式淘汰原因清單，不要容許自由文字。按固定周期與市場部一起覆核這些數字：「沒有預算」的上升指向目標客戶選擇，「無回覆」的上升指向接觸節奏或線索來源。只保留一個版本的圖，令流程變更出現在它的歷史紀錄裡，而不是出現在一封電郵裡。

常見問題

MQL、銷售已接納線索與 SQL 有甚麼分別？

它們標記的是三次不同的交接和三個不同的負責人。市場合格線索（MQL）已經達到市場部的評分門檻並被移交出去；在這張圖裡，那就是「是否達到 MQL 門檻？」的「是」分支。銷售已接納線索（SAL）是銷售部已同意去跟進的那一條——正因如此，接納被畫成一個由客戶經理回答的決策，而不是一次自動的狀態變更。銷售合格線索，或者說合格商機，是在需求探詢會議上通過了資格評定、並且確實有機會變成一宗交易的那一條。需求瀑布模型把它們分開是有理由的：沒有接納這一步，市場部呈報的是已交付的線索，銷售部呈報的是它從未接手的線索，而這兩個數字無法對上。

一段接觸節奏應該有多少次接觸，才把線索退回培育？

並不存在一個值得引用的通用數字，而那些作為最佳做法流傳的數字，通常來自某一家供應商的資料集，而不是來自你們的市場。請依據你們自己的證據來訂定：你們用哪些渠道、你們的購買周期有多長，以及在你們自己的資料裡，回覆由第幾次接觸開始消失。在結構上真正重要的是：這段節奏是有限的、寫下來的，並且被執行——因為一段沒有盡頭的節奏永遠不會正式用盡，於是線索既沒有被跟進，也沒有被釋放。這也正是圖中「是否收到回覆？」帶有一條明確的「無回覆」分支、而不是一條隱含分支的原因。

我們該用 BANT 還是 MEDDIC 來做資格評定？

它們回答的是不同的問題。BANT（預算、決策權、需求、時機）是一道配合度與準備度篩選，一位稱職的 SDR 可以在第一次交談中完成，因此它是一道合理的交接關口。MEDDIC（量化指標、經濟決策人、決策準則、決策流程、已識別的痛點、內部支持者）是一套用於審視交易的框架，為多持份者的複雜銷售而建；你很少能在第一次通話裡弄清決策流程或找到內部支持者。一種常見的安排是：以 BANT 作為交接的資格評定，在接納之後於商機內部補齊 MEDDIC。MEDDPICC 是同一套框架，另外擴展了簽約流程與競爭態勢。選定一種，把它寫在圖上，並把它的欄位設為必填。

一條始終沒有回覆的線索該怎樣處理？

把它退回培育，而不是刪掉。在這個範本裡，「無回覆」分支不會直接走向一條已關閉的紀錄；它先到「記錄淘汰原因代碼」，再到「退回培育還是淘汰？」，由後者決定把線索送回培育還是關閉它。沒有回覆通常是時機訊號，而不是配合度訊號，這條線索日後可能會再次達到評分門檻。兩點實務提醒：記錄線索的來源以及你們聯絡它的依據；並逐一核對你們開拓的每個司法管轄區對未經請求的電子推廣的規定，各地並不相同——在香港，《非應邀電子訊息條例》為商業電子訊息訂立了規則。請向你們機構中負責市場推廣合規的人確認細節。

被客戶經理拒絕的線索歸誰負責？

必須有人負責，否則它就停在那裡。這張圖把被退回的交接送到銷售經理那裡：他要麼維持退回——那麼線索走上原因代碼路徑，被退回培育或淘汰——要麼推翻退回，於是它變成一個已接納的商機。把這次裁決畫出來的價值在於，拒絕變得可見、可點算。如果多數退回都被維持，說明資格評定準則執行得太寬鬆；如果多數被推翻，說明你們的客戶經理在推掉本該接下的工作。這兩件事都值得知道，而當被拒絕的線索只是無聲地飄回市場部、沒有留下紀錄時，兩件事都不會浮現出來。