由銷售線索到訂單流程圖：由收集到訂單登記
由銷售線索到訂單流程圖範本：收集與去重複、線索評分與 MQL 關卡、SDR 接觸與銷售接納、CPQ 設定、折扣審批、報價接納、信貸審核與銷售訂單登記。
甚麼是由銷售線索到訂單流程圖：由收集到訂單登記流程
由銷售線索到訂單是一條紀錄的鏈條，不是一套銷售打法。它由線索被收集的那一刻開始——網頁表格、展覽掃碼、轉介、來電，或者一次名單匯入——直到一張已簽署的訂單被登記並放行給履行為止。令它成為一條流程而非一張漏斗圖的，是同一項商業事實在途中改了四次名字、四次落腳處：市場推廣系統裏的線索，在 CRM 變成聯絡人與客戶，再變成商機，在 CPQ 工具裏變成一份設定好的報價，最後在 ERP 變成一張銷售訂單。下面這張圖跟著一條線索走完這四段。它連同來源被收集，與 CRM 現有的紀錄比對，補充資料並評分，越過市場推廣的門檻後派給 SDR，由客戶經理接納或退回，再設定、定價，在折扣超出銷售本身權限之處交上審批，帶著有效期發出報價，然後簽署、過信貸審核、登記入帳。
這張圖止於已登記的訂單。下游一概不畫：執貨、付運、簽收證明、開票、收款銷帳與追收屬於循環中由訂單到收款那一半，有它們自己的圖；而環繞價格的更深一層商務機制——完整的多層折扣階梯、非標準條款的法務審閱、收入認列——則放在由報價到收款那一頁。上游的邊界同樣是刻意的。CRM 內部的線索生命週期，連同區域規則、輪流指派、節奏設計、重用次數上限與資料衛生，本身就是一條獨立流程，在這裏被壓縮成三個方格。銷售打法則完全沒有畫：沒有持份者地圖，沒有商業論證，沒有共同行動計劃，因為那些屬於銷售管道與複雜 B2B 銷售的圖。由銷售線索到訂單所擁有、而它的鄰居並不擁有的，是紀錄在橫跨那四套系統時的完整性。來源在轉換之後仍然保得住嗎？報價與訂單對得上嗎？六個月之後，還有人講得出是哪個推廣活動帶來這筆收入嗎？
四個判定撐起整張圖，而每一個都被刻意放在特定的泳道裏。「CRM 內是否已有紀錄？」在市場推廣營運裏、在其他任何事情發生之前就被回答，因為在這裏造出的一份重複紀錄，會在此後每一步重新冒出來：第二位負責人、第二份報價、被分薄的歸因。「評分是否達到 MQL 門檻？」同樣留在市場推廣營運，因為這是市場推廣自己的判斷，也因為它是全圖唯一容許一條線索停下來等待、而不是繼續向前的關卡。「銷售是否接納該線索？」放在客戶經理而不是 SDR 團隊那一格，因為接納是接收方講的話，一次由交付方自行宣布完成的交接並不算交接；它的三個出口，把退回去再做多些功課與徹底判定不合適分得清清楚楚。兩道價格關卡分處兩條泳道，好讓議下這個價錢的人永遠不是批准這個價錢的人；而「信貸審核是否通過？」坐在最後的財務／信貸泳道裏，在那裏它仍然攔得住一張所有人都已經慶祝過的訂單。
本流程圖涵蓋的內容
本範本包含
- 六條泳道（市場推廣營運、SDR 團隊、客戶經理、交易審核組／銷售營運、財務／信貸、客戶）鋪在六個階段上：收集、資格評定、銷售接納、設定與報價、審批與接納，以及訂單與交接。
- 先去除重複，再補充資料：「CRM 內是否已有紀錄？」把重複的查詢引向「併入現有的客戶紀錄」，而不是再開一條線索，這樣該客戶就只有一位負責人、一段歷史和一條歸因軌跡。
- 一道給線索留了等候之處的評分關卡：「評分是否達到 MQL 門檻？」把低於這條線的一切送去「把線索留在培育流程」，那裏是重新評分而不是刪除，於是日後轉熱的線索會由同一道關卡再次進入。
- 雙向接納，而不是把交接拋過牆去：「潛在客戶是否在 SLA 內回覆？」管的是 SDR 團隊的首次接觸窗口，而「銷售是否接納該線索？」有三個出口，其中之一是「按原因代碼淘汰」。
- 報價編製帶兩道各自獨立的關卡：「設定是否符合產品規則？」把無效的設定退回客戶經理，而「折扣是否在客戶經理權限內？」只把價格一項升級到另一條泳道上的「交易審核組是否批准該折扣？」。
- 一條接納迴路和最後一道硬關卡：「客戶是否接納報價？」讓修改經「修訂報價並重新定價」折返到折扣判定，而「信貸審核是否通過？」仍然可以在「在 ERP 登記銷售訂單」之前攔下一宗已簽署的交易。
何時使用本範本
- 你們正在把市場推廣自動化、CRM、CPQ 工具與 ERP 接駁起來，需要在有人動手對應欄位之前，先議定紀錄在系統之間的交接
- 市場推廣與銷售對線索質素各執一詞，雙方都拿不出一份寫下來的定義：交出去的到底是甚麼，接手的人又該拿它做甚麼
- 報價要好幾天才發得出去，卻沒有人講得出時間是花在設定上、花在折扣審批上，還是花在等客戶上
- 有些訂單被登記了下來，但財務根本不會讓它過信貸，又或者它與客戶實際簽署的那份報價對不上
- 有人問哪幾個推廣活動帶來收入，答案卻死在線索紀錄與銷售訂單之間的某個位置
運作方式
把泳道改成你們自己的崗位
把市場推廣營運、SDR 團隊、客戶經理、交易審核組／銷售營運、財務／信貸、客戶，換成你們真正擁有的崗位。很多機構既沒有 SDR，也沒有交易審核組：如果客戶經理自己開拓客戶、由銷售經理裁定折扣，那就把這些泳道合併，而不是畫一次沒有人執行的交接。無論還合併了甚麼，都請保留客戶那條泳道，因為它的兩個方格是整條流程唯一離開你們自己大樓的地方。
把「合格」與「接納」的意思寫下來
在兩道資格關卡都帶上判定準則之前，這張圖是死的。寫清楚哪些匹配屬性、哪些意向行為加起來構成分數，門檻本身是多少，再另外寫清楚客戶經理接納時到底答應了甚麼：通常是一位有名有姓的人、一項講得明白的需求，以及一個說得通的時間窗。把兩份定義與市場推廣、銷售在同一間房裏議定，記下是誰簽的名，並為它們定一個複核日期。
定下首次接觸的 SLA 與重用規則
決定線索派出去之後 SDR 必須在多久之內完成首次接觸、跨哪些渠道、多少次嘗試才算跑完一輪節奏，以及窗口關閉時會發生甚麼。然後議定重用規則：一條線索要在培育流程裏留多久才可以重新評分，以及它最多可以轉幾個圈，之後就該被淘汰而不是再評一次分。沒有後面這條規則，培育流程就會變成線索悄悄死去的地方。
為折扣權限配上數字
給兩道價格關卡配上數字。定下客戶經理可以自行讓出多少、權限到哪裏為止，並且同時以相對牌價的百分比和一個絕對金額表達，免得一張很大的訂單上那一點點百分比被當成例行公事。再決定這道判定量度的是表面折扣，還是扣除交付成本之後餘下的毛利，並寫明這份報價是按哪一版價目表定價的。
界定一份發出的報價必須載有甚麼
列出文件上必須出現的內容：版本編號、有效期、貨幣與稅務處理、範圍之內包括甚麼以及明確不包括甚麼，還有它所帶的審批，連同審批人與日期。修訂要出新版本而不是覆蓋舊版，這樣紀錄裏仍然看得出客戶簽的是哪一份報價、當時為它批過甚麼。這一步現在幾乎不用花甚麼成本，日後卻正是它回答了審計的提問。
議定信貸規則與登記前的核對
寫明由誰做信貸審核、依據哪些材料、訂單金額超過多少才需要做。把財務可以附加、而不必直接拒絕的條件記下來，例如預付款、調低的信貸額度、更短的付款期或一份擔保，以及誰有權同意這些條件。然後加上登記前的核對：在有人把訂單放行給履行之前，已簽署的訂購單與銷售訂單之間必須有哪些內容對得上。
拿三宗真實交易走一次
找一宗一路直通的交易、一宗在折扣迴路裏繞了兩圈的，以及一宗被淘汰的，與當初經手的人一起把每一宗都在圖上走一次。凡是有人講得出、圖上卻沒有畫的步驟，或者畫了、實際卻總被跳過的步驟，都是發布之前值得動手處理的發現。把圖改成實際發生的樣子，而不是改成打法手冊說應該發生的樣子。
常見問題
由銷售線索到訂單的流程有哪些步驟？
線索連同來源與同意被收集下來，與 CRM 比對之後，要麼併入現有客戶，要麼作為新線索繼續向前。它獲補充資料，並按匹配度與意向評分，低於市場推廣門檻的一切都留在培育流程裏等候重新評分，而不是被刪掉。合格的線索交給 SDR，由他在首次接觸窗口內跑完一輪接觸節奏，確認需求並約下會議。之後客戶經理接納它、退回去要求補做功課，或者按原因代碼淘汰它。一旦接納，就建立商機，設定方案並以產品規則校驗，再按現行價目表定出價格。折扣在客戶經理本身權限之內的，直接去發報價；超出的交給交易審核組。報價帶著有效期發出，客戶簽署、要求修改，或者任由它過期；財務做信貸審核；最後銷售訂單獲登記，並歸因回帶來它的那個推廣活動。
由銷售線索到訂單與由報價到收款有甚麼分別？
它們切在不同的位置，回答的也是不同的問題。由銷售線索到訂單起於剛收集到的原始線索，止於已登記的訂單，所以它的細節全在一宗交易成為商業事實之前必須發生的那些事情上：去除重複、補充資料與評分、市場推廣門檻、SDR 的接觸節奏、銷售接納、商機、設定與報價。由報價到收款起點較後，由一個合格商機開始，把前半段當作已經完成，把細節放在定價審批、非標準條款、開票、收入認列與收妥的現金上。由訂單到收款起點更後，由一張你已經接下來的訂單開始。如果你們的問題是線索質素、市場推廣到銷售的交接，或者報價要多久才發得出去，就用這一頁；如果問題是審批階梯、開票觸發條件或者把錢收回來，那就用另外兩頁。
MQL、銷售已接納線索與 SQL 有甚麼分別？
它們是三個不同的人對同一份紀錄作出的三種判斷，而由 SiriusDecisions（現時屬於 Forrester）推廣開來的需求瀑布模型，存在的意義正是把它們分開。市場合格線索滿足了市場推廣自己的準則，通常是匹配屬性與觀察到的意向的組合，被視為可以跟進。銷售已接納線索是銷售看過並同意去做的線索，它印證了市場推廣的準則確實有被滿足。銷售合格線索則是銷售做過、並依據預算、決策權、需求與時間窗等證據確認為真實商機的線索。在這張圖裏，市場推廣門檻產出第一種，銷售是否接納該線索這道判定產出第二種，緊接其後建立的商機是第三種。把三者壓成一個數字的圖，正是市場推廣與銷售由同一個資料庫報出不同管道數字的原因。
由銷售線索到訂單的流程通常在哪裏斷開？
四個可以預料的位置，而且沒有一個是銷售本身。一是收集時造出的重複紀錄，原因是去除重複的檢查被跳過，或者配對規則太窄，於是下游每一份文件都存在兩份。二是市場推廣到銷售的交接：線索被派了出去，卻從來沒有被接納或拒絕，誰都講不出它們後來怎樣，兩邊各拿一套數字爭論。三是折扣審批：權限只寫成相對牌價的百分比，於是透過付款期、更長的爬升期或免費服務讓出去的那一份，就一路未經檢驗地過了關。四是報價與訂單之間的接縫：簽署的一份與登記的一份漸漸分岔，因為它們住在兩套系統裏，而開票時只會去讀其中一套。這四處都是發生在邊界上的斷裂，也正因如此，只有把這條鏈條由頭到尾畫出來，它們才看得見。
收集一條銷售線索時必須記錄甚麼？
最少要記錄：帶來它的渠道與推廣活動、日期與時間、對方在入口處被告知了甚麼，以及你們打算據以聯絡對方的合法依據。電子推廣的規則因司法管轄區而異，也視乎聯絡人是誰。在英國，Privacy and Electronic Communications Regulations 並不把電郵推廣規則套用於有限公司、LLP 這類法團訂戶，但 ICO 把獨資經營者與普通合夥視為個人訂戶，因此對他們需要取得同意或適用 soft opt-in；無論屬於哪一種，UK GDPR 對某位具名人士的工作電郵地址依然適用，取消接收的要求亦必須獲執行。在美國，CAN-SPAM 法案要求取消接收的要求在十個工作天內獲執行、取消機制在發出後最少三十天內保持可用，並且訊息須載有一個有效的實體郵寄地址。這張圖是一個供你們按照自身程序與法律意見調整的起點，而不是一份合規聲明。