詢問要確認到什麼程度，才交給業務？Forrester 需求瀑布：MQL 與 SQL 的由來

你是不是也遇過這些情況？

• 「行銷說名單很多，業務說能談的沒有幾個？」兩邊數的東西不一樣；需求瀑布先把每一個階段的定義講清楚，大家數的才是同一件事。
• 「詢問進來，要問到什麼程度才交給業務？」需求瀑布在行銷與業務之間設了一個交接點：達到約定的條件才交出去，業務要明確表示接受或退回。
• 「交給業務的詢問，後來怎麼了，沒有人知道？」每一則都記下停在哪個階段、為什麼被退回；退回的理由，正是下一次判斷要修正的地方。

先認識需求瀑布：B2B 行銷與業務共用的商機分段標準

需求瀑布是 SiriusDecisions 提出的 B2B 商機模型，現在由 Forrester 延續與改版。

• 誰提出：SiriusDecisions，2001 年由 John Neeson 與 Rich Eldh 創立的 B2B 研究顧問公司。2018 年 11 月宣布由研究機構 Forrester 收購，2019 年初完成。
• 是什麼：描述並衡量一則詢問從留下資料到成交的過程，維基百科形容它是 B2B 企業廣泛使用的模型。
• 版本：2012 年改版，加入電話開發的階段；2017 年改成以「購買小組」為單位；2021 年 5 月，Forrester 推出 B2B 營收瀑布。
• 厲害的地方：行銷合格名單（MQL）與業務合格商機（SQL）這兩個詞，就是由這套模型帶進 B2B 行銷與業務的日常用語。

官方網站：forrester.com ↗

需求瀑布的五個階段：從留下資料到成交

最早的需求瀑布，把一則詢問分成五個階段。每一個階段都有定義，也有負責的人：

每往下一層，數量就變少，像瀑布一樣一層一層落下來。重點不在名字，而在每一層的定義是行銷與業務一起講好的：什麼樣的詢問算 MQL、業務接到之後怎麼判斷、多久要處理，事先寫清楚，月底對數字時，兩邊說的才是同一件事。

交接點：業務要接受或退回，每一則都有紀錄

需求瀑布最重要的設計，是行銷與業務之間的交接點。行銷交出一則名單，業務要明確表示接受或退回，系統記下是哪一種；退回的，也要寫下理由，例如預算不符、窗口不對、只是在收集資料。

這個設計解決的，是最常見的那種模糊：名單交出去之後，沒有人知道業務有沒有打、為什麼沒有下文。有了接受與退回的紀錄，行銷知道哪一類名單最常被退回，回頭調整判斷的條件；業務也不用再收到一堆說不清楚的名單。交接的標準，就在一次一次的退回裡越來越準。名單、詢問與有效商機怎麼分，可以看〈名單很多，業績卻沒起色？〉。

2012 年的改版：行銷與業務之間，多了電話開發這一段

2012 年改版的需求瀑布，在行銷與業務之間加入了電話開發（teleprospecting）的階段：行銷帶來的名單，先由專責的人打電話確認，再交給業務；名單的來源也分開追蹤，行銷帶來的、電話開發找到的、業務自己開發的，各算各的。這一段，就是現在常說的 SDR（業務開發代表）在做的事。把它寫進模型，代表 B2B 企業已經把「先打電話確認、再交給業務」當成一個獨立的階段，有自己的定義、負責的人與數字。這段分工的由來，可以看〈業務為什麼要分成兩段？〉。

從一個人到一群人：2017 年與 2021 年的改版

2017 年，SiriusDecisions 把計算的單位，從「一則名單」改成「一個購買小組」：同一家公司裡，為了同一個需求一起評估的幾個人，算成同一個商機。2021 年 Forrester 推出的 B2B 營收瀑布延續這個方向，並把既有客戶的續約、加購也算進商機。

Forrester 在發表時引用的研究指出，超過 80% 的 B2B 採購屬於複雜的採購情境；在需要共識的採購裡，95% 牽涉三個人以上、兩個以上的部門。一則詢問背後，常常是一群人：使用的人、做決定的人、管預算的人。只問到其中一位，就以為需求確認完成，是很常見的落差。採購小組怎麼運作，整理在〈一筆 B2B 採購背後有幾個人在做決定？〉。

中小企業可以先學的一件事：寫下交接的定義，和一張退回理由表

中小企業不需要導入整套模型，但可以先把交接這一段寫清楚。一張紙就夠，舉個例子（示意）：

• 什麼時候交給業務：知道用途、大概的數量或預算、什麼時候需要，以及誰會一起決定。
• 業務多久回覆：接到之後兩個工作天內聯繫，並在紀錄上標「接受」或「退回」。
• 退回的理由：預算不符、時程太遠、窗口不對、只是收集資料，四選一，再加一句說明。
• 每個月回頭看：哪一種理由最多，下個月交接前就多問那一題。

這張表用一兩個月，行銷與業務對「好的詢問」就會有同一個標準。常見的判斷條件，可以參考〈客戶說有興趣，值不值得跑一趟？〉。

中小企業想照著做，會遇到哪些困難

大企業能把需求瀑布跑起來，背後是中小企業很難一次備齊的條件：

• 分開的角色：行銷、電話開發與業務各有專責的人，交接點才有意義。
• 記錄的工具：每一則名單停在哪個階段、被接受或退回，都要有系統記下來。
• 足夠的詢問量：每個月有一定數量的詢問，各階段的轉換率才看得出意義。

把一則詢問走過的路拆開來看，差距會更清楚：

中小企業不需要五個階段都設一個人，但需要在詢問與業務之間，有人先打電話、照同一個標準把需求問清楚，再交給業務。這個位置，在國外叫 SDR（業務開發代表）。

想學需求瀑布，常見的三個誤區

• 只換名詞，不寫定義：把名單改叫 MQL、SQL，卻沒有寫下每一層的條件，兩邊數的還是不同的東西。
• 交出去就不管：沒有接受與退回的紀錄，就看不出哪一類詢問常被退回，標準永遠不會變準。
• 只問到一個人：採購常常是一群人一起決定；問到使用的人，不代表做決定的人也同意。

可以先問自己：你們公司交給業務的詢問，有沒有一個寫下來的標準？業務退回的詢問，理由有人記下來嗎？

常見問題

這些工作，現在由誰負責？

詢問進來之後，誰照同一個標準把需求問清楚？交給業務的，有沒有寫清楚確認了什麼、還沒確認什麼？我們把網站、廣告與第一通電話這幾段交給你：集客網站與 Google 搜尋廣告讓正在找解決方案的人主動詢問；由 Tshutlink 業務開發代表（T-SDR）回電，確認需求、預算、時程與決策角色，每一則確認過的商機都分級交給你的業務；還在評估的，T-SDR 持續跟進、問清楚後更新等級。分級的方式整理在〈Tshutlink 業務開發代表〉；其他國家的企業怎麼做，整理在我們可以向誰學習？想知道你的詢問該怎麼分級，可以先跟我們聊 3～5 分鐘。

立即導入 Tshutlink 集客式商機開發服務