MQL 和 SQL 的差別，不是行銷部和業務部各自背一套縮寫，而是你要不要把每張表單、每個下載、每則 LINE 詢問都立刻丟給業務。對台灣 SME 來說，MQL 比較像值得繼續培養的名單，SQL 才是已經符合目標客群、也出現高意圖行為，值得立刻安排電話、報價或會議的名單。只要先把交接線定清楚，行銷才知道該繼續餵什麼內容，業務也才不會覺得所有名單都只是浪費時間。
MQL 和 SQL 真正差在哪，不是術語而是交接時機
HubSpot 對 MQL 與 SQL 的核心區分很直接：MQL 已經表現出興趣，但還沒準備好接受業務直接推進；SQL 則已經達到可交給 sales 的 readiness。這也是目前 SERP 上最常見、也最實用的切法。HubSpot
Salesforce 在 2026 年 6 月 9 日更新的 SQL 指南則把生命週期拆成 Lead、MQL、SQL、Opportunity、Closed Won/Lost，並明確指出 SQL 通常已符合 ICP，且做出 booking demo、request pricing、request quote 或要求和業務談的高意圖動作。Salesforce ANZ
這兩種說法對台灣 SME 都很有用，因為它們都把焦點放在一件事：MQL 不是爛名單，SQL 也不是只要填單就算。真正的分界，在於對方是不是已經準備好進入人工成交流程。
先別吵名單好不好，先把 MQL 和 SQL 的工作分開
如果 MQL 與 SQL 沒有被分開，小團隊最常發生兩種錯：第一種是業務一整天都在追還沒準備好的名單；第二種是本來已經想買的人，卻還被塞在培養流程裡等下一封 EDM。HubSpot 也直接提醒，剛被判成 SQL 的名單若放著不處理，最糟的結果就是讓競爭對手搶先接走。HubSpot
對老闆或營運主管來說，這不是部門術語問題，而是工時配置問題。MQL 要解的是教育、比較、釐清需求；SQL 要解的是速度、對話、報價與下一步承諾。只要兩種名單被混在一起，後面的 CRM、LINE 標籤、GA4 事件和名單成本都會一起失真。
台灣 SME 最常用的 4 個 MQL / SQL 交接條件
最穩的做法不是背一套教科書定義，而是先約定 4 個交接條件。只要對方同時達到這幾條，才從 MQL 進 SQL；若還差一段，就繼續留在培養或補資料流程。
| 交接條件 | 還在 MQL 的常見樣子 | 可以進 SQL 的常見樣子 | 誰該接手 |
|---|---|---|---|
| 目標客群適配度 | 有互動，但產業、地區、客單價或需求型態還不確定 | 已符合 ICP，且需求落在你真的能交付的範圍 | 行銷先篩，業務確認 |
| 需求明確度 | 只是下載資料、看文章、追蹤社群，還在摸索問題 | 已說出需求、時程、預算帶、採購角色或具體想比較的方案 | 業務或 SDR |
| 高意圖行為 | 看教學文、訂閱電子報、參加 webinar、加 LINE 但沒有下一步 | 要求報價、預約諮詢、重看價格頁、回覆 nurture 信、要求與業務通話 | 業務優先接手 |
| 時間窗口 | 可能會買，但沒有近期決策節奏 | 這週或這個月內要比較、提案、開會或決定供應商 | 業務 24 小時內跟進 |
這張表的重點，是讓團隊知道 SQL 必須同時有 fit 與 intent，而不是只看哪個廣告來源比較熱鬧。若只是填表後完全沒有高意圖動作，多半還是 MQL；若已經要求報價、約時間，卻還被丟回自動培養，通常就是交接線設太慢。
哪些行為還只是 MQL，哪些訊號已經該進 SQL
HubSpot 把下載 ebook、參加 webinar、點開 nurture email 這類行為放在 MQL 側；把反覆查看 pricing page、要求 demo、看案例與比較頁、回信問具體問題這類行為放在 SQL 側。這種切法很適合 SME，因為它比抽象分數更容易落地。HubSpot
若你的入口主要是 LINE 官方帳號，邏輯也一樣。加入好友、看圖文選單、點教學內容，多半還只是 MQL；如果對方直接問價格、預約空檔、交期、方案差異，或補上公司規模與時程，這類訊號通常就值得進 SQL。不要因為入口不是表單，就以為無法判斷 intent。
Salesforce 的 SQL 文章也特別強調，不同行業的 SQL 動作會不一樣。SaaS 可能是 demo 或 trial，專業服務可能是 request quote 或 meeting，在地服務可能是 booking consult 或 request treatment options。這代表台灣 SME 不該照抄別人的條件，而要把高意圖動作翻成自己產業真的會出現的動作。Salesforce ANZ
怎麼把 MQL / SQL 接到 GA4、CRM、LINE 與業務 handoff
如果你的系統裡只有 `generate_lead`，那你永遠只知道有名單進來，卻不知道哪些名單真的被確認成值得追的 lead。Google Analytics 官方建議事件把這條漏斗拆得很清楚：`generate_lead` 代表送出表單或留下資訊，`qualify_lead` 代表已符合 qualified lead 條件，`working_lead` 代表有代表開始聯絡，`close_convert_lead` 則代表真的成為客戶。Google Analytics Help Google for Developers
Google Analytics 的 Lead acquisition report 也直接用 `generate_lead`、`qualify_lead`、`close_convert_lead` 來填 New leads、Qualified leads、Converted leads。這個設計對台灣 SME 很有價值，因為它提醒你：MQL 和 SQL 不能只寫在 Slack 討論裡，而要回到可量測事件。Google Analytics Help
實務上可以這樣接：表單送出、加 LINE、下載資料先記成 `generate_lead`；行銷或業務確認符合 ICP 並有明確需求後，才記 `qualify_lead`；真正排進第一輪電話、報價或 meeting，記成 `working_lead`；成交後再記 `close_convert_lead`。這樣你才看得出哪個渠道只是收名單，哪個渠道真的把 MQL 推進 SQL。
交接規則也要搭配回覆 SLA。HubSpot 明講，SQL 一旦出現，最糟的是讓它躺著不處理；很多成交差異，最後其實不是內容問題，而是速度問題。對多數 SME 來說，SQL 若能在 24 小時內被接手，漏失率通常比拖到兩三天後低得多。HubSpot
7 天內可落地的 MQL / SQL handoff SOP
如果你現在沒有完整 CRM 也沒關係，先用最小版本跑起來就夠。第一天，拉出最近 20 到 30 筆名單，標記哪些最後有報價、預約、成交，哪些只是下載或加好友。第二天，把這些案例整理成 4 個交接條件，避免每個人靠感覺判斷。第三天，替每個入口定義一個高意圖動作，例如報價、預約、電話、meeting 或補資料。
第四天，把名單狀態至少分成 Lead、MQL、SQL、Working、Won/Lost 五層。第五天，把 `generate_lead`、`qualify_lead` 與 `working_lead` 接回 GA4 或試算表欄位。第六天，替 SQL 設一個明確回覆 SLA，例如上班時間 4 小時內、非上班時間隔日上午前。第七天，回看哪個來源 MQL 多但 SQL 少，哪個來源 SQL 高但成交低，再決定你要修培養內容、報價流程，還是業務話術。
哪些公司適合先做，哪些先不要急著做
這套做法最適合有表單、LINE、預約、詢價或報價流程，而且會發生行銷交業務、客服交業務、或多人輪值接手的台灣 SME。像是 B2B 顧問、課程招生、裝修設計、醫美與診所周邊服務、在地高客單服務、設備商與專案型銷售，都很適合先把 MQL 與 SQL 切開。
如果你現在最大的問題其實是流量很少、定位不清楚、服務頁講不明白，或根本還沒有固定 follow-up 流程，那先不要急著做複雜 handoff。這時更該先補 offer、頁面、表單與基本回覆 SOP，否則你只是替混亂的流程多加兩個縮寫。
另外，若你打算把 MQL / SQL 自動化到 AI 或規則引擎，也要記得 BANT 這類框架仍只是輔助，不是保證。Salesforce 對 BANT 的說法很直接：Budget、Authority、Need、Timeline 可以幫助你更有效分辨哪些 lead 值得追，但前提是團隊真的願意用同一套問題與紀錄方式判斷。Salesforce
資料更新與來源
本文於 2026 年 8 月 4 日整理，主軸聚焦在台灣 SME 的名單交接規則，而不是推薦單一 CRM。MQL、SQL、lead lifecycle 與高意圖行為，主要依據 HubSpot 與 Salesforce 的公開說明；GA4 事件與報表命名則依 Google Analytics Help 與 Google for Developers 當前文件為準。
重要來源包括：HubSpot MQL vs. SQL guide、Salesforce ANZ SQL guide、Google Analytics recommended events、Google Analytics Lead acquisition report、Google Analytics event reference，以及 Salesforce BANT guide。其中 HubSpot 與 Salesforce 部分內容帶有各自平台語境，因此本文只引用可泛化的 qualification 與 handoff 原則，不直接照搬工具導向建議。
結論：先把交接線講清楚，名單品質才有得談
MQL 和 SQL 真正要解的，不是讓團隊學會兩個英文縮寫，而是把『誰該繼續培養、誰該立刻交給業務』說成同一套規則。對台灣 SME 來說，最穩的起點通常不是再買一套新工具，而是先定 4 個交接條件，再把 `generate_lead`、`qualify_lead`、`working_lead` 與成交結果接回同一張表。當大家都用同一條線看名單，業務才比較不會嫌名單爛，行銷也才知道哪些來源真的值得繼續投。
FAQ
MQL 和 SQL 一定要照國外 SaaS 的定義嗎？
不用。核心原則是 fit 加上 intent，但高意圖動作要翻成你產業真的會出現的行為，例如報價、預約、meeting、補資料或來店安排。
只要填表單，就能算 SQL 嗎？
通常不建議。表單送出多半只代表 generate_lead，若還沒有需求明確度、ICP 適配或高意圖動作，較適合先留在 MQL。
LINE 詢問也能分 MQL 和 SQL 嗎？
可以。加入好友、看內容、點選單多半還是 MQL；若直接問價格、時程、預約或報價細節，通常就更接近 SQL。
GA4 一定要做 qualify_lead 事件嗎？
如果你想看出哪些來源不只帶來表單，而是真的帶來可跟進名單，qualify_lead 會比只看 generate_lead 更有用。
小公司沒有 SDR，還需要做 MQL / SQL handoff 嗎？
需要，只是角色可以簡化成老闆、客服或業務自己。重點不是組織多大，而是同一個人也要用一致規則分出先培養和先成交的名單。