最近 B2B SaaS 圈多了一個職位:GTM Engineer(Go-To-Market Engineer)。Apollo 這類公司在大力介紹它,說這是「用工程的方式做 revenue(營收)」的人。
這個角色確實有意思,但要看懂它「為什麼現在才出現」,不能直接跳進去。得先把三塊地基鋪好:GTM 是什麼、Sales Pipeline 和 CRM 是什麼、然後 AI(尤其 agent)怎麼改變這一切。這篇就照這個順序,一層一層講。
一、GTM 是什麼
GTM(Go-To-Market),中文常說「進入市場」,指的是一家公司把產品送到對的客戶手上、並說服他們買的整套動作。
它不是某個部門,是一條橫跨好幾個部門的「動作鏈」:
- Marketing(行銷) 負責讓對的人知道你、對你有興趣(製造需求、帶進名單);
- Sales(銷售) 負責把有興趣的人變成付錢的客戶(跟進、談判、成交);
- Customer Success(客戶成功) 負責讓客戶留下來、續約、買更多。
一家公司「怎麼有系統地把東西賣出去」,就是它的 GTM motion(進入市場的打法)。有的靠業務主動出擊(outbound,主動開發),有的靠內容和產品自己吸引人上門(inbound,被動引流)。不管哪一種,最後都要回答同一個問題:我要找誰、怎麼找到他、怎麼讓他往「成交」走。
而「往成交走」這條路,在 B2B 世界有個具體的載體——Sales Pipeline。
二、Sales Pipeline 與 CRM:GTM 的落地載體
Sales Pipeline(銷售管道),是一筆生意從「陌生名單」走到「成交」所經過的階段。 典型的 B2B pipeline 長這樣:
| 階段 | 意思 |
|---|---|
| Lead | 剛進來的名單,還沒判斷合不合適 |
| MQL | Marketing Qualified Lead——行銷判定「值得跟進」的名單 |
| SQL | Sales Qualified Lead——業務接手後,確認值得投入的名單 |
| Opportunity | 確認有需求、有預算,變成一筆「機會」 |
| Negotiation | 報價、談判 |
| Closed Won / Lost | 成交,或告吹 |
團隊也會用各階段的成交機率,估算這條管道大概能帶來多少營收——這就是每天在看的「pipeline 健不健康」。
這條 pipeline 住在哪裡?住在 CRM(Customer Relationship Management,客戶關係管理系統)——像 Salesforce、HubSpot 這種軟體。CRM 是整個銷售的「系統紀錄(system of record)」:每個聯絡人、每家公司、每筆機會、每一次互動,都記在裡面。Sales Pipeline 就是 CRM 裡那條看得見、可以往前推的主線。
搞清楚這層關係,GTM 的目標就具體了。(先講清楚範圍:接下來聚焦「獲客到成交」這一段;完整 GTM 還包含成交後的留存與擴張,也就是 Customer Success 那塊,這篇先不展開。)在獲客到成交這段,GTM 存在的意義,就是把這條 pipeline 填滿、並讓它順利往下走:
- 填上游:讓對的人進來——找到符合 ICP(Ideal Customer Profile,理想客戶輪廓,也就是「哪類客戶最適合你」) 的名單;
- 推中游:讓他們從一個階段走到下一個(評分、跟進、觸及、分派給對的業務);
- 保乾淨:別讓資料爛掉、別讓名單漏接(data hygiene,資料衛生)。
GTM 在哪裡 add value(創造價值)? 因為 pipeline 不會自己填滿,也不會自己保持乾淨。總得有人決定:要找誰(ICP、以及 TAM——Total Addressable Market,整體潛在市場有多大)、怎麼判斷誰比較熱(scoring,評分)、缺的資料怎麼補(enrichment,資料增補)、怎麼觸及(outreach,對外接觸)、進來要分給誰(routing,名單分派)。 這些工作以前散在 marketing ops、sales ops、RevOps(Revenue Operations,串接行銷、銷售與客戶成功的營運職能) 好幾個角色身上。GTM Engineer,就是把這一串重新打包成「工程化、可規模化的系統」的人。
到這裡都還沒講到 AI。這個角色的骨架,其實在 AI 之前就存在——只是現在,AI 把它的重要性一口氣放大了。
三、從 data-driven 到 agent-first:方法論的演進
同樣一件事(填滿並推進 pipeline),做法一直在進化。
早期:憑經驗。 業務看著 CRM 儀表板,靠直覺決定先打給誰。
接著:data-driven(數據驅動)。 不再只憑直覺,而是用資料佐證判斷——lead scoring 用「公司規模、產業、有沒有互動」算出分數,分數高的先跟。決策依據從「感覺」變成「資料」。這一步,很多成熟團隊早就在做了。
現在:AI-driven,而它的實踐方式叫 agent-first。 這裡先說清楚 agent 是什麼:它是能根據一個目標、自己呼叫工具、連續執行多個步驟的 AI 系統——不是一問一答的聊天機器人。 過去資料只是「拿來看的」,人再據以判斷;現在 agent 可以自己去做這些事——自動研究一家公司、補齊缺的欄位、寫出客製化的開場白、算出分數、決定分派。agent 從「輔助人看資料」升級成「主要的執行者」。這就是 agent-first:讓 agent 跑在前線,人的角色往上移——去設定目標、規則與審核關卡。
這是真正的躍進。但這裡有一個關鍵前提,決定 agent-first 到底是資產還是災難:
如果沒有一套 workflow(有固定輸入、步驟與檢查點的流程)約束它,agent 的輸出可能很不穩定,也可能一本正經地生成沒有根據的內容。
換句話說,agent-first 能不能 add value,不在 agent 本身多聰明,而在有沒有一套流程把它框起來。這裡要特別提醒一個容易混淆的地方——這套流程,跟前面的 Sales Pipeline 是兩件事:
- Sales Pipeline 是生意推進的階段(Lead→…→成交);
- 這裡講的是 agent 工作流(agent workflow)——一套技術流程,規範 agent 拿到什麼輸入、走哪些步驟、輸出要通過哪些檢查。
後者是用來讓前者跑得更快、更乾淨的。 有了 agent 工作流這層支撐,agent 才能同時做到「靈活」和「受控」;沒有它,agent 只是個講得頭頭是道、但你不敢直接採信的黑盒。下一個問題,就是:怎麼判斷 agent 吐出來的東西,能不能交給下一步?
四、怎麼讓 agent 的輸出乾淨地為 pipeline 加值
核心是一個很簡單的觀念:agent 吐出來的,先當「資料(data)」,不是「事實(fact)」。 agent 產的當然還是資料——但要能被下一步安全使用的,才叫「資訊(information)」。中間這道「把 data 升級成 information」的轉換,就是 agent 工作流真正的價值。
做這道轉換,先給每個欄位標上它的來源可信度(provenance),分四層:
| 層級 | 內容 | 怎麼對待 |
|---|---|---|
| facts | 有來源、時間、負責人的事實 | 唯一能當「真相」用的 |
| signals | 可能過期或不全的觀測 | 帶上時效,別當事實 |
| derived | 推算出來的欄位(如分數) | 記下算法、版本、信心值、到期日 |
| generated | agent 生成的內容、假設 | 不自動升級為事實 |
然後定清楚:一筆資料要從低可信度層「升級(promote)」到高可信度層,得滿足什麼條件。舉一條完整的流程你就懂了——假設你的 agent 在研究某家目標公司:
- agent 產出一句「這家公司最近在擴充資安團隊」。這一刻它是 generated——agent 自己講的,可能對、也可能是幻覺。先原封不動標成 generated,不准它直接寫進 CRM 的事實欄位。
- 接著去找根據:比方在該公司官網找到三則資安職缺,本月發佈。有了來源 + 時間,這句話從「agent 說的」變成「有憑據的觀測」,升級成 signal,寫進 CRM 時附上「來源:官網徵才頁,2026-07」。
- 如果來源夠權威、夠穩定(例如公司公開財報寫明資安投資),它甚至能支撐一個 fact 欄位。
- 另一邊,scoring 模型吃進這個 signal + 公司規模 + 互動紀錄,算出「值得優先跟進,分數 0.72」——這個分數是 derived,要記下用了哪個模型版本、信心多少、何時到期。
走完這條路,「data 怎麼變成 information」就具體了:agent 吐的原始一句話是 data;經過「標層級 → 找來源 → 查證 → 記版本」的處理,才變成下一步(業務、或下一個 agent)能安全使用的 information。
而其中最要守住的一條規則是:generated 的東西,不直接冒充 fact。 因為一旦一個沒查證的推測被寫成事實,下游所有人、所有後續的 agent 都會信它——一個幻覺,就這樣污染了整條 pipeline。反過來,只要守住這條,agent-first 就是純加值:它把「研究公司、補資料、寫初稿、評分」這些原本很吃人力的事大幅加速,同時因為每樣輸出都標清楚了層級,整條 pipeline 反而更透明、更好維護。agent 讓 pipeline 跑得更快,工作流讓 agent 跑得可信——兩者互相成就。
五、人站在哪裡
agent-first 不代表「人退出」,而是人換了位置。在一套設計良好的 GTM 系統裡,人守在三個點上:
- 訂目標——「這一季要打哪個市場區隔、什麼樣的客戶算好客戶」,這由人定,不由 agent 定;
- 與 agent 協作——人給方向和限制,agent 提方案和草稿,人來修、退回、或放行;
- 最後審查與負責——尤其是不可逆、會影響品牌聲譽的動作(對外寄信、寫進客戶紀錄),人要在關卡上點頭。
這不是不信任 AI,而是責任的本質:執行可以委派給 agent,責任不行。 對外寄一封帶著幻覺內容的信、把錯的資料寫進客戶的 CRM——這些後果落在公司和個人身上,不落在 agent 身上。所以一個務實的原則是:驗證成本配得上風險的地方,放手讓 agent 自動跑;風險高、不可逆的地方,讓它停在「草稿」,等人審過再發。
這也順帶回答了「為什麼這個角色叫 Engineer」:因為他真正負責的,是這套系統在真實運轉時的行為、失誤模式與資料品質——分派給錯的業務、損害寄件網域的信譽、把假資料混進大家共用的 CRM。這些是工程責任,不是「會用工具」就能扛的。
六、所以,GTM Engineer 是誰
把前面這幾層疊起來,這個角色就清楚了:
GTM Engineer 是懂 GTM、懂 Sales Pipeline 與 CRM、並且會用 agent 工作流把 AI 框成「可靠加值工具」的人。 他做的是:設計那套讓 agent 乾淨地填滿並推進 sales pipeline 的流程,守住資料品質,並把人留在該負責的位置上。
給不同的人,幾句帶走的話:
- 想入行的人:別把「會用某個 outreach 工具」當本事。耐久的價值,是能對一整條 pipeline 的運轉與資料品質負責。工具會換,這份責任不會。
- Revenue leader(營收主管):先把流程和資料規則建好,再談自動化;對外動作預設人審;別把「買了一個平台」等同於「有了一條乾淨的 pipeline」。agent 能不能真的省人力、降成本,要用你自己的數字驗證,不是聽願景。
- 台灣 B2B SaaS:美式那套重 outbound 的打法,不見得直接適用於關係型銷售、通路、或較小的市場——但「分層 + 不讓生成內容冒充事實」這條資料紀律,跟市場大小無關,在你自己的 CRM 上一樣成立。
AI 把 GTM 從「人看資料做判斷」帶到「agent 在受控的工作流上執行」。這波轉變是真的,而且正在發生。但它不是「全自動取代人」的終局——真正的樣子,是一套讓 agent 既靈活又受控的工作流,加上一個守住目標、品質與責任的人。GTM Engineer,就是把這兩件事接起來的人。
本文以 Apollo.io 對 GTM Engineer 的介紹為引子(該文也在推廣其平台「讓 agent 自動跑、人只審高優先帳戶」的願景)。文中 Sales Pipeline / CRM 為 B2B 通用概念;四層來源可信度(provenance)與「生成內容不冒充事實」的升級(promotion)規則,是本文提出的 v0.1 實務框架,不是官方標準。
Top comments (0)