MQL SQL 差異真正重要的，不是行銷跟業務背不背得出英文全名，而是你有沒有把「什麼名單先留在行銷培育、什麼名單可以交給業務、交出去多久內要回、退回來要寫什麼理由」講清楚。對多數台灣中小企業來說，MQL 是已經有興趣、但還不值得立刻追單的名單；SQL 則是已經同時具備適配度、購買意圖與下一步行動條件的名單。如果這條線沒畫清楚，最後通常是業務覺得名單很冷，行銷覺得業務都沒追，真正熱的機會反而在兩邊中間漏掉。
這篇適合誰，不適合誰
這篇適合三種團隊。第一種，是已經有表單、LINE、廣告名單或官網詢問，但交給業務後常常石沉大海的公司。第二種，是公司不大，行銷和業務甚至是同一批人，沒有空把每一筆詢問都人工慢慢判讀。第三種，是已經有 CRM 或至少有 Google Sheet，卻還沒有一致交接規則的團隊。
如果你現在連服務對象、平均客單價、常見成交條件都還沒整理，這篇不會是第一步。因為 MQL 跟 SQL 的定義一定要建立在「什麼客戶值得接、什麼需求不該接」之上，否則只是把混亂換成另一個英文縮寫。
MQL 和 SQL 的差異到底要看哪 4 件事
Adobe 的 MQL 與 SQL 指南把兩者的核心差異講得很直接：MQL 已經對品牌或內容有興趣，SQL 則已經更接近購買決策，關鍵差別在於購買意圖是否明確。這也是為什麼很多公司不是沒有名單，而是把還在看資料的人，太早當成可以直接成交的人。Adobe
第一件事看適配度。這個人是不是你的目標客群，產業、地區、預算帶、服務範圍有沒有對上。第二件事看意圖。他是下載資料、訂閱電子報，還是主動問價格、要報價、約 demo、問導入時間。第三件事看決策條件。Salesforce 在 MQL to SQL 檢查表裡提醒，轉成 SQL 前至少要補到需求、利害關係人、購買時程這些資訊，否則交接出去也只是把不完整的工作轉給業務。Salesforce
第四件事看下一步是否明確。HubSpot 的生命周期設定把 Sales Qualified Lead 後面再拆成 New、Open、In Progress、Connected、Bad Timing 等子狀態，這其實在提醒一件事：SQL 不是「這個人不錯喔」而已，而是已經值得進入可追蹤的業務節奏。HubSpot Knowledge Base
| 比較面向 | MQL | SQL | 常見誤判 |
|---|---|---|---|
| 互動深度 | 看過內容、留資料、下載資源、開信或點信 | 主動問報價、約 demo、詢問導入與交付時程 | 把所有表單都當成高意圖 |
| 責任歸屬 | 行銷先培育與補資訊 | 業務接手確認商機與下一步 | 交接後沒有 owner |
| 需要資料 | 來源、需求方向、基本適配度 | 需求、決策人、預算或價格承受度、時間 | 名單只有姓名電話就丟單 |
| 回覆節奏 | 可以進內容培育或再行銷 | 要有明確 SLA 與首次回覆時限 | 熱名單排到兩天後才看 |
| 退回規則 | 回到培育池，補內容或補資料 | 若不合格，要寫清楚退件原因 | 只說「名單很冷」但沒有原因 |
中小企業最實用的名單交接表：誰培育、誰跟進、多久回
中小企業不用一開始就做很重的 lead scoring。先把交接規則做成一張人人看得懂的表，通常比追求 0 到 100 分的模型更有用。因為你的問題多半不是分數不夠精，而是交接時點太亂、回覆太慢、退件太模糊。
HubSpot 在 lead management 的實務說明裡，把「何時從 MQL 轉到 SQL」和「多久內要跟進」放在同一組問題裡。這很重要，因為如果你只定義 MQL、SQL，卻沒有定義時限，實務上還是會卡住。它也明確建議，新名單最好在很短時間內就被回覆，否則熱度會快速流失。HubSpot Blog
| 名單狀態 | 誰負責 | 建議第一步 | 首次回覆時限 |
|---|---|---|---|
| MQL | 行銷或內勤 | 補上來源、需求方向、下載或瀏覽脈絡 | 同一天完成整理 |
| 高意圖 MQL | 行銷先確認後交接 | 檢查是否符合服務範圍，補齊重點摘要 | 4 小時內完成交接 |
| SQL | 業務 | 電話、LINE 或 Email 擇一先聯繫，確認下一步 | 同工作日內 |
| Bad Timing | 業務退回行銷 | 寫明原因並排回培育節奏 | 退回當天 |
| Unqualified | 業務或主管 | 標記不符合條件的原因，避免重複誤交 | 判定當天 |
如果你現在只有 1 到 3 個人兼做行銷與業務，我會建議把規則壓縮成一句話：有明確需求加上明確下一步，才交業務；其餘先培育。 這句話雖然簡單，但比一堆沒有被執行的術語更有效。
退件理由一定要寫，不然行銷永遠學不到
很多團隊不是不會交接，而是只會交出去，不會收回來。業務追了一輪後如果只回一句「這批很冷」，行銷其實學不到任何東西。下一次投放、內容、表單設計照樣重犯，雙方只會繼續互相抱怨。
最少要固定 5 種退件理由：沒預算、沒決策權、需求不合、時程太後面、資料不完整。Salesforce 在 BANT 說明裡把 Budget、Authority、Need、Timeline 當成最基本的資格架構，對中小企業來說，這四個欄位不一定要做成正式分數，但很適合拿來當退件語言。Salesforce
退件理由寫得夠清楚，行銷下次才知道要修哪裡。若常常是「沒決策權」，代表表單或內容吸到太多執行端；若常常是「時程太後面」，代表這批名單比較適合 nurture，而不是立刻交業務。這些都會直接影響你後面的內容主題、廣告受眾與表單問題。
怎麼把 MQL、SQL 與 SLA 放進 CRM 或 Google Sheet
如果你有 CRM，先做三件事：一，建立 lifecycle stage 或等效欄位；二，建立 lead status 或交接結果欄位；三，為 SQL 增加首次回覆時間欄位。HubSpot 的官方文件甚至示範，可以用「進入 Sales Qualified Lead 超過幾天」來觸發跟進提醒。這說明交接不是只看分類，還要看時間。HubSpot Knowledge Base
如果你現在只有 Google Sheet，也可以先用 6 欄上線：來源、需求摘要、MQL/SQL、owner、首次回覆時間、退件理由。不要嫌土，很多公司的真正問題不是工具太爛，而是規則根本沒寫。只要欄位設對，後續要搬到 CRM 也不難。
真正需要自動化的，不是所有判斷都交給 AI，而是讓 AI 先做整理、摘要、標記與提醒，讓人保留最後的交接判斷。這樣既能加快速度，也能避免把不該追的名單包裝成熱名單。
資料更新與參考來源
本文於 2026 年 6 月 21 日整理。
本文用到的定義與流程依據，主要來自 Adobe 的 MQL/SQL 差異說明、Salesforce 的 MQL 轉 SQL 檢查表與 BANT 架構、HubSpot 的 lifecycle stage / lead status 文件，以及 HubSpot 對 lead management 的實務建議。
不同產業的名單價值、成交周期與人力配置差很多，所以回覆時限與交接門檻應以你的客單價、服務模式與實際回覆能力調整，而不是照抄任何一家平台的教科書。
- Adobe: MQL vs. SQL
- Salesforce: MQL to SQL checklist
- Salesforce: What is BANT?
- HubSpot: lifecycle stages and lead status
- HubSpot: lead management
結論
MQL 跟 SQL 的差異，說到底是在幫團隊決定「這個人現在該被誰處理、要在多久內處理、如果不處理要付出什麼代價」。對台灣中小企業來說，最值得先做的不是更複雜的模型，而是把交接門檻、首次回覆時限與退件理由寫成一套可執行規則。只要這三件事先落地，你的名單品質、業務效率與行銷回饋速度，通常都會比只討論術語更快改善。
FAQ
MQL 一定要用分數制才算正式嗎？
不一定。對中小企業來說，先用明確條件判斷通常比硬做分數制更容易落地，例如有沒有符合服務範圍、是否主動問價格、是否已經留下可聯絡資訊。
SQL 一定代表很快就會成交嗎？
不一定。SQL 代表值得進入業務跟進節奏，不代表一定會買。它至少表示這筆名單已經有足夠資訊、足夠意圖，值得業務花時間確認下一步。
名單交接 SLA 應該怎麼訂才不會太理想化？
先從你做得到的時限開始，例如同工作日內回覆 SQL、4 小時內完成高意圖 MQL 交接。先守住執行率，再逐步縮短，不要一開始訂出團隊根本做不到的標準。
如果業務常把名單退回，代表行銷做錯了嗎？
不一定。重點是退件理由是否清楚。如果退回時能明確標示沒預算、沒決策權、需求不合或時程太後面，行銷就能修正表單、內容與投放；若只是說名單很冷，雙方都學不到。
沒有 CRM，只用 Google Sheet 能做 MQL / SQL 管理嗎？
可以。至少先建來源、需求摘要、MQL/SQL、owner、首次回覆時間、退件理由這 6 欄。只要欄位與規則清楚，即使用試算表也能先把交接流程跑順。