MQL SAL SQL 不是行銷術語考試，而是名單交接責任表。對多數台灣 SME 來說，MQL 代表行銷判定「值得交給業務」的名單，SAL 代表業務在 SLA 內確認「這筆我接」，SQL 才代表業務真的確認有需求、有機會往成交推進。若這三段沒有切開，你看到的就會是行銷說名單有興趣、業務說名單不能打、老闆看 CRM 卻看不出到底卡在哪一段。
MQL、SAL、SQL 為什麼會讓行銷和業務一直互相怪罪
很多團隊把所有有填表單的人都叫做高品質名單，但實際上，下載資料、加 LINE、詢價、預約會議、回電話，代表的購買意圖完全不同。HubSpot 在 MQL vs. SQL 頁面先把差異講白：MQL 還在教育或研究階段，SQL 才是 ready for direct sales engagement。這種開頭會贏，不是因為術語新，而是它直接回答了讀者最想知道的責任分界。
但只分 MQL 和 SQL，通常還是不夠。因為從「值得交接」到「業務真的接手」之間，常常還有一段沒人管的灰區。Salesforce 在 sales and marketing alignment 頁面也明講，SLA 至少要包含 qualified lead 定義、跟進時限、退回理由與雙方責任。也就是說，真正讓流程順起來的，不是再吵一次誰定義比較對，而是把交接規則寫成制度。
先把三個階段講白：哪一段算行銷、哪一段算業務
如果你是台灣 SME，最實用的切法不是做成超複雜漏斗，而是先把三個階段用責任講白。
| 階段 | 誰負責 | 定義 | 常見訊號 | 下一步 |
|---|---|---|---|---|
| MQL | 行銷 | 符合基本客群，且出現值得交接的興趣或意圖 | 填高意圖表單、看過價格頁、主動加 LINE 詢問、預約諮詢 | 送到業務待接受池 |
| SAL | 業務 | 在 SLA 內確認這筆名單可接、可聯絡、不是垃圾或重複 | 聯絡資訊有效、對口正確、不是學生作業或求職訊息 | 建立跟進任務或退回原因 |
| SQL | 業務 | 已確認有需求、時程、預算或明確下一步 | 約到合格會議、需求明確、可進提案或報價 | 進入商機或 deal stage |
HubSpot 的 lifecycle stage 文件也支援這種想法。它把 Marketing Qualified Lead、Sales Qualified Lead、Opportunity 放在同一條 stage 邏輯裡，並且說明 Sales Qualified Lead 還可以搭配 Lead Status 子階段。這代表你完全可以把「是否已被業務接受」單獨記錄，不必硬塞進同一個欄位裡。
台灣 SME 可直接照抄的名單交接表
下面這張表，適合目前名單主要來自網站表單、LINE、Meta 即時表單、Google Ads 電話來電或轉介的團隊。你不用先買新工具，先把規則定出來比較重要。
| 項目 | 建議做法 | 為什麼重要 |
|---|---|---|
| MQL 條件 | 至少同時看客群 fit 和意圖訊號，不要只看有沒有填單 | 避免把低意圖下載者和真正詢價者混在一起 |
| SAL SLA | 上班時間進件 24 小時內接受或退回；急件 2 小時內判定 | 把「沒空處理」和「不值得處理」分開 |
| 退回原因 | 固定選單，例如非客群、資料錯誤、重複名單、純比價、無需求時程 | 讓行銷知道該修流量、文案還是表單 |
| SQL 條件 | 至少有明確需求與下一步，例如合格會議、估價需求、提案需求 | 避免業務把所有已讀訊息都當商機 |
| 回顧指標 | 每週看 MQL→SAL、SAL→SQL、接受時長與退回理由 | 交接問題才看得出卡在哪一段 |
如果你團隊很小，甚至老闆自己兼行銷和業務，SAL 也一樣有意義。因為 SAL 不是為了多設一個術語，而是強迫你在 CRM 或 Google Sheet 裡留下「我接了」或「我不接」的決策痕跡，後面才有辦法回頭看流量品質和跟進效率。
CRM 欄位、退回原因與 SLA 該怎麼設
Salesforce 在交接教學裡提醒，單靠 scoring 還不夠，真正投入銷售資源前還要再做 qualification。這對台灣 SME 特別重要，因為很多名單不是從單一管道進來，而是網站、LINE、電話、廣告表單混著來。如果沒有欄位和退回原因，大家只會各自憑感覺說這筆好或不好。
最少請先有這幾個欄位：
- Lead source：網站表單、LINE、Meta 即時表單、Google Ads、電話、轉介紹。
- MQL date：行銷認定可交接的日期。
- SAL status：接受、退回、待確認。
- SAL date：業務接受日期。
- Disqualification reason：退回原因固定選單。
- SQL date：確認為 sales-qualified 的日期。
若你用的是 HubSpot，官方文件也指出 lifecycle stage 的時間欄位可以追蹤各 stage 的進出時間，甚至能用 workflow 去抓某個人進入 SQL 太久還沒動作的情況。即使你不是用 HubSpot，概念也一樣：沒有日期，就沒有 SLA；沒有退回原因，就沒有改善線索。
7 天內導入 MQL、SAL、SQL 的做法
你不需要先做半年 CRM 專案。對大多數 SME，先做一個 7 天導入版就夠了。
- 盤點最近 30 筆名單，分來源、是否有回覆、是否成交。
- 拉一次行銷和業務會議，先定義什麼算 MQL，什麼情況業務可以退回。
- 決定 SAL 的接受時限，例如上班時間 24 小時內一定要接受或退回。
- 把退回原因做成固定選單，不要每個人自己自由輸入。
- 在 CRM、Google Sheet 或表單後台補上 MQL date、SAL date、SQL date 欄位。
- 設定每週固定 20 分鐘回顧，看哪個來源最常被退回、哪位 owner 最常超時。
- 兩週後再調整 MQL 條件，不要一開始就做過度複雜的 lead scoring。
如果你是以 LINE 為主的團隊，可以把 SAL 視為「業務已接手這則對話」的狀態，不一定要等進 CRM 才算。重點是一定要留下接受或退回紀錄，不然表面上是回覆慢，實際上是根本沒有人明確接手。
每週要看的 4 個交接指標
這類文章若只講概念，很容易最後又回到互相指責。真正能把流程拉回正軌的，是每週固定看這四個指標：
- MQL→SAL 接受率：行銷送出的名單，有多少被業務接受。
- SAL→SQL 轉換率：業務接手後，有多少真的進入可成交機會。
- 平均接受時長：名單從交接到被接受，花了多久。
- 前 3 大退回原因：到底是流量錯、表單錯，還是客群就錯。
Salesforce 也把 MQL-to-SQL conversion、cycle time 與 shared metrics 放進 alignment 指標裡。對 SME 來說，不必一開始追太多 KPI，但至少要讓這四個數字每週看得到，否則你永遠只能憑印象判斷哪個渠道值得投。
更新與適用範圍
本文於 2026 年 7 月 27 日整理，主要參考 HubSpot、Salesforce 與相關可開啟 benchmark 頁面。適用情境以台灣中小企業常見的網站表單、LINE、廣告表單、電話詢問與輕量 CRM 為主；如果你是大型 call center 或超長銷售週期 B2B 組織，SLA 時限與欄位會需要再細分。
- HubSpot Blog: MQL vs. SQL: What they are and how they differ
- HubSpot Knowledge Base: Use contact and company lifecycle stages
- Salesforce: Sales and Marketing Alignment
- Salesforce Trailhead: Qualify and Route Leads to Your Reps
FAQ
MQL、SAL、SQL 一定都要有嗎？
不一定每家公司都要用一模一樣的名稱，但你一定要把「行銷認定可交接」、「業務確認接手」、「業務確認有商機」這三個責任切點分開。就算你把 SAL 改叫已接受名單，邏輯也不能少。
如果團隊只有 2 個人，還需要 SAL 嗎？
需要。團隊越小，越容易以為自己心裡知道就好，但最後最常發生的就是兩邊都以為對方會處理。SAL 的價值在於留下明確接手紀錄，不在於公司規模大小。
退回原因應該寫得多細？
原則是要細到能改善來源與表單，但不要細到每個人都懶得選。先用 5 到 8 個固定選項就夠，例如非客群、重複名單、聯絡不到、純比價、學生作業、無明確需求。
MQL 條件應該由行銷還是業務決定？
要共同決定。Salesforce 的 alignment 架構也強調雙方共同語言和回饋機制。行銷可以主導來源與意圖判斷，業務必須提供哪些訊號其實無法成交，兩邊一起修才有用。
什麼時候才算 SQL？
當業務已確認需求、對口、時程或明確下一步時，才算 SQL。不是已讀、不是回過一次訊息、也不是留下電話就算。若沒有明確商機跡象，寧可停在 SAL，也不要把 CRM 看起來很滿卻沒有真商機。
FAQ
MQL、SAL、SQL 一定都要有嗎？
名稱可以不同，但「行銷認定可交接」、「業務確認接手」、「業務確認有商機」這三個責任切點一定要分開。少了任何一段，交接問題就很難被量化。
如果團隊只有 2 個人，還需要 SAL 嗎？
需要。團隊越小，越容易靠默契處理，但也越容易出現兩邊都以為對方會跟進。SAL 的作用是留下明確接手紀錄。
退回原因應該設哪些？
先用固定選單，例如非客群、資料錯誤、重複名單、聯絡不到、純比價、學生作業、無明確需求。重點是讓行銷可以根據原因修來源與表單。
MQL 條件該由誰決定？
行銷和業務要共同決定。行銷負責來源與意圖訊號，業務負責補上哪些訊號其實無法成交，兩邊一起校正才有效。
什麼時候才算 SQL？
當業務已確認需求、對口、時程或明確下一步，例如合格會議、估價需求、提案需求，才算 SQL。不是已讀訊息或留下電話就算。