MQL SQL 真正要解決的，不是把名單貼上兩個英文縮寫，而是讓行銷知道哪些人先培養、業務知道哪些人該立刻接手、老闆知道哪些來源真的會成交。對台灣 SME 來說，最實用的做法不是先做很複雜的評分模型，而是先把定義、接手欄位、回覆時限、退回條件與 GA4 事件說清楚，這樣表單、LINE、電話與報價名單才不會各走各的。
MQL、SQL 真正要解決的是什麼
很多團隊以為 MQL 跟 SQL 只是 B2B 行銷術語，其實它們解決的是一個更現實的營運問題：到底什麼樣的名單值得佔用業務時間。當行銷把任何填表都算成成果，業務就會覺得名單很水；當業務只肯追已經準備買的人，行銷又會覺得辛苦做來的名單被浪費。這不是誰比較努力，而是雙方沒有共享的過件標準。
Salesforce Trailhead 在 lead qualification 教學裡講得很直接：名單要同時看適合度與行為訊號，例如產業、公司規模、職稱、是否看過網站、是否參加 webinar、是否主動要求 demo。它甚至明講，要求 demo 的權重應高於單純瀏覽網站，因為兩者的購買意圖不同。參考 Salesforce Trailhead: Qualify and Route Leads to Your Reps。
換句話說，MQL 與 SQL 不是漏斗圖上的裝飾，而是幫你把「有興趣」和「值得現在追」分開。這個區分越清楚，回覆速度、成交率、內容培養與報表歸因就越容易對齊。
MQL 與 SQL 怎麼分，才不會交錯人
最簡單的分法是這樣看：MQL 是已經表現出興趣，但還不一定準備跟業務對話的人；SQL 是已經出現明確購買訊號，值得交給業務直接處理的人。HubSpot 的 lifecycle stages 也把這條路徑寫得很清楚，先是 Lead，再進到 Marketing Qualified Lead，之後才是 Sales Qualified Lead、Opportunity、Customer。參考 HubSpot Knowledge Base: Use contact and company lifecycle stages。
如果用台灣 SME 常見情境翻譯，下載型錄、訂閱電子報、加 LINE 後點過服務介紹、參加線上說明會，通常比較像 MQL；主動留下預算範圍、詢問可執行時程、要求報價、要求 demo、想約顧問通話、要看方案細節，才更像 SQL。問題不是這些行為有沒有發生，而是你的團隊是否事先約定：做到哪一步才交給業務。
很多公司卡住的原因，是把「有留下資料」直接等於 SQL。這會讓業務第一時間看到很多其實還在比價、蒐集資訊、或只是想先拿資料的人。短期看名單量很漂亮，長期則會讓業務對行銷來源失去信任。
| 名單狀態 | 比較像哪一類 | 常見訊號 | 建議下一步 |
|---|---|---|---|
| 剛填表或剛加 LINE | MQL | 留下基本資料、下載內容、看服務頁 | 先做培養與補問，不急著交業務 |
| 主動要求報價或 demo | SQL | 有明確問題、時程、預算或購買目的 | 交業務並設定回覆 SLA |
| 資料不完整但有高意圖 | MQL 待補件 | 只寫一句想了解、沒有情境與需求 | 先補問必要欄位再決定是否過件 |
| 不符合客群或需求不對 | 不合格名單 | 服務範圍不符、預算落差大、只是求職或合作邀約 | 標記原因，避免再次誤交 |
台灣 SME 最實用的 4 個名單交接規則
1. 先寫出「什麼叫過件」，不要只寫分數
小團隊不一定一開始就要做 100 分制，但一定要先把過件條件寫出來。至少回答四個問題：對象是不是目標客群、問題是不是你真的在解、時程是不是近期、下一步是不是願意跟真人對話。若這四件事有三件都不明確，先不要急著丟給業務。
Salesforce 的建議很值得借鏡：不要只看單一行為，而要同時看 fit 跟 engagement。也就是說，標題職稱、公司型態、地區、需求型別是一邊；下載、重複瀏覽、索取方案、回覆問題是另一邊。兩邊都夠強，才更接近 SQL。
2. SQL 一定要有 owner、SLA、必填欄位
很多公司說自己有 SQL，實際上只是名單從表單跳到信箱。真正能用的 SQL，至少要附帶三樣資訊：由誰接手、最慢多久要回、接手前要知道哪些欄位。HubSpot 在 lifecycle stage 文件中甚至示範，可以用「Date entered Sales Qualified Lead 超過 5 天」觸發 follow-up workflow，這表示交接延遲本身就應該被看見，而不是靠人記得。參考 HubSpot lifecycle stages。
對台灣 SME 來說，第一版不用太複雜。可以先規定：所有 SQL 都必須有聯絡方式、需求類型、來源、預估時程、負責人與最近一次互動摘要；進到 SQL 後 24 小時內一定要有人處理，否則自動提醒。
3. 退回培養不是失敗，是正常流程
不是每一筆 MQL 都會變 SQL，也不是每一筆 SQL 都應該一路往前推。若業務發現對方只是蒐集資訊、預算太遠、時程延後、或內部尚未成案，就應該有明確的退回培養條件，而不是把它留在業務名單裡一起老化。這一步做得好，名單數字才不會看起來很多，實際上卻沒人在動。
HubSpot 也把 Sales Qualified Lead 下面拆成 New、Open、In Progress、Attempted to Contact、Connected、Bad Timing、Unqualified 等 lead status。這個設計很實用，因為它提醒你：SQL 不是終點，而是接手後還要持續分流。參考 HubSpot 的 Lead Status 說明。
4. 報表一定要能看到來源品質，不只看名單量
如果你只能看到每週新增幾筆名單，卻看不到哪些變成 qualified、哪些被接手、哪些最後成交，那麼 MQL / SQL 只是換了一套比較漂亮的叫法。Google Analytics 的 Lead acquisition report 很值得參考，它把 generate_lead、qualify_lead、close_convert_lead 直接做成報表指標，表示名單交接若沒有事件定義，後面很難看來源品質。參考 Google Analytics Help: Lead acquisition report。
對小團隊最實際的做法是先看四層：哪個來源帶來 generate_lead、哪個來源最常進到 qualify_lead、哪些 qualified lead 有人真正接手、最後哪些來源變成 close_convert_lead。這樣你才能分出表單量大但成交差的來源，和名單量不多但成交率高的來源。
表單、LINE、電話與報價單怎麼共用同一套標準
台灣 SME 的問題很少是完全沒有名單，而是名單散在不同入口。官網表單記在 Email、LINE 詢問留在聊天記錄、電話詢問只寫在紙本、報價單又在另一個試算表。結果同一家公司或同一個需求，可能被當成三筆不同名單。
第一版整合不需要先買大型 CRM，但至少要共用同一張交接欄位表。無論來源是表單、LINE、電話或門市，都先記同一組欄位：姓名或公司、聯絡方式、需求類型、來源、地區、時程、預算區間、最近互動、目前狀態、下一步、負責人。只要這張表穩，後面接到 CRM、LINE 標籤或報表都會容易很多。
真正要避免的，是每個渠道各自定義 qualified。官網表單說有填手機就算 SQL，LINE 認為有回貼圖就算熱客，電話紀錄覺得只要問價格就算業務名單，最後根本沒辦法一起看。
GA4 與 CRM 要記哪些事件與欄位
若你希望後面能回答「哪種內容或廣告真正帶來可成交名單」，就不能只記 submit form。Google Analytics 的推薦事件把整條 lead funnel 寫得很清楚：generate_lead 是提交資料，qualify_lead 是被標記成合格名單，working_lead 是與代表接觸或被代表接觸，close_convert_lead 是最後成為客戶。參考 Google Analytics Help: Recommended events 與 Lead acquisition report。
這組事件的價值，不是教你一定要照英文縮寫工作，而是提醒你名單不能只有「送出」與「成交」兩個狀態。中間至少還要有 qualify 跟 working，否則你永遠不知道是來源不對、過件太鬆，還是業務根本沒有跟進。
| 營運動作 | 建議事件 / 欄位 | 為什麼要記 |
|---|---|---|
| 表單送出、LINE 留資料、門市留聯絡方式 | generate_lead | 知道哪些來源真的有帶來名單 |
| 確認符合客群與需求 | qualify_lead | 分出名單量和合格名單量 |
| 業務已聯絡或已安排通話 | working_lead | 看到交接後是否真的有人接 |
| 成交 | close_convert_lead | 把來源與營收結果接起來 |
| 不合格或時機不對 | disqualify_lead / lead status | 避免一直重複交錯人 |
若你現在還沒有 GA4 事件或 CRM 自動化，也可以先用試算表跑一版。重點是欄位與狀態先一致，之後再把事件送進系統。系統晚一點接，通常不是最大風險；定義一開始就不一致，才會讓之後每張報表都互相打架。
7 天導入 SOP
第 1 天：把最近 30 筆名單攤開
不要先開會討論理論，先把最近 30 筆表單、LINE、電話或報價名單拿出來。看哪些其實不該交給業務、哪些該交卻沒有人追、哪些成交了但沒有回頭標記來源。這一步會比空想一套完美漏斗更快看到問題。
第 2 天：寫出 MQL 與 SQL 的最低標準
每家公司標準不同，但一定要寫成一句能執行的規則。例如：MQL 是已留下有效聯絡方式，且需求與服務方向相符；SQL 是已說明需求情境，願意接受報價、demo 或通話，且時程在 90 天內。先求能用，不求高大上。
第 3 天：決定 owner 與 SLA
如果今天來一筆 SQL，到底誰接？幾小時內接？超過多久提醒？這些不寫，交接永遠只會停在信箱。第一版可以很簡單，例如平日白天 4 小時內、夜間或假日次一工作日上午前，由指定負責人處理。
第 4 天：統一欄位與狀態
不管你用試算表、LINE 標籤或 CRM，都先統一欄位。至少包含來源、需求類型、時程、負責人、目前狀態、最近互動與下一步。沒有這些欄位，後面即使裝了 CRM，也只是在搬亂資料。
第 5 天：補 GA4 或最小報表事件
若技術資源夠，就開始把 generate_lead、qualify_lead、working_lead、close_convert_lead 補進量測。若暫時做不到，也至少先在試算表留下這四個狀態欄位，讓每週回顧時看得到掉在哪一段。
第 6 天：挑一個來源先試跑
先從最常見、最容易出錯的來源開始，例如官網詢價表單、LINE 自動回應後的人工接手、或廣告導來的 demo 預約。不要第一週就想一次整合所有入口，先把單一路徑跑順，之後再擴大。
第 7 天：回看退件與成交原因
第一輪回顧請不要只看新增名單數。要同時看：哪些被退回培養、哪些被標成不合格、哪些已接手但沒有推進、哪些最後成交。這些回饋會比單純多開廣告，更能幫你修正 MQL / SQL 標準。
適用與不適用情境
這套做法最適合有網站表單、LINE 詢問、報價需求、顧問諮詢、課程報名、預約型服務、B2B 商務詢價，或需要先過濾需求品質的台灣 SME。它尤其適合行銷與業務常互相抱怨「名單很多但不會成交」的團隊。
它不適合完全沒有穩定名單來源、沒有明確產品服務範圍、或每一筆需求都高度客製、無法先定義最低標準的團隊。若你的主要問題是根本沒有詢問，不是先談 MQL / SQL，而是先修定位、入口與內容。
資料更新與來源
本文於 2026-08-02 依當前可查的官方文件整理，重點使用 Salesforce、HubSpot 與 Google Analytics 的公開說明。平台介面、欄位名稱與報表位置後續可能更新，但「先定義、再交接、再量測」這個原理不會因工具版本改變而失效。
Salesforce Trailhead: Qualify and Route Leads to Your Reps、HubSpot Knowledge Base: Use contact and company lifecycle stages、Google Analytics Help: Lead acquisition report、Google Analytics Help: Recommended events
限制也要先講清楚：本文提供的是中小企業名單交接框架，不保證每個產業都適合同一套門檻，也不代表用了 MQL / SQL 名詞就一定會提高成交率。真正有效的前提，仍然是你有把需求、來源、時程與接手責任記錄下來。
結論
MQL SQL 的價值，不在於漏斗圖看起來比較專業，而在於你終於能回答三個問題：這筆名單是不是值得現在追、交給誰追、追完怎麼知道有沒有價值。對台灣 SME 來說，先把定義、欄位、SLA、退回條件與報表事件訂清楚，再談更複雜的 lead scoring 或自動化，通常會比一開始就追求大系統更快見效。
FAQ
MQL、SQL 一定要用很複雜的分數模型嗎？
不一定。對多數台灣 SME 來說，第一版先把目標客群、需求類型、時程、是否願意對話這幾個過件條件寫清楚，比先做精細分數更重要。分數可以後補，但標準不能沒有。
只要有人填表，就能算 SQL 嗎？
不建議。填表通常只代表 generate_lead，還不代表對方已具備足夠購買意圖。若沒有需求情境、時程、預算或下一步意願，多半應先留在 MQL 或待補件狀態。
沒有 CRM，還能做 MQL / SQL 名單交接嗎？
可以。你可以先用試算表、LINE 標籤與固定欄位試跑，只要來源、狀態、owner、下一步與跟進紀錄一致，就能先建立最小可用流程，之後再升級工具。
名單被退回培養，算是業務沒做好嗎？
不一定。若需求時機未到、預算還沒成形、或對方只是蒐集資訊，退回培養反而是正常流程。關鍵是要標記退回原因，避免下次又用同樣標準誤交。
GA4 一定要記哪些事件，才能看出名單交接品質？
最實用的最小集合通常是 generate_lead、qualify_lead、working_lead、close_convert_lead。這四個事件能幫你分開看新增名單、合格名單、已接手名單與最後成交，不會只停在表單量。