After Code : GTM engineer

近期，AI Engineer YouTube 頻道在 8/27 集中分享了許多關於 GTM 的影片，裡面有不少公司把自己如何找客戶、理解客戶、安排銷售流程和導入 AI 的做法講得很具體。我想很值得把這些內容整理一下分享，而過程中最明顯的感受是，GTM 目前仍然很難。難的地方不在於能不能生成一封 email，而在於公司能不能知道該找誰、何時聯絡、用什麼內容、由誰負責，並且在錯誤發生時把影響控制住。

Notion 的 Flora Liu 把 GTM 描述成分散式系統問題。客戶只有一段旅程，公司裡的行銷、銷售、客戶營運和產品團隊卻各自使用 Salesforce、Gong、Outreach、ZoomInfo、Snowflake、筆記和文件等工具。資料可能互相衝突，重要資訊可能藏在會議紀錄裡，外部工具之間也會產生延遲。比如 champion 已經離職、客戶要求暫停聯絡，這些資訊如果只存在一份非結構化筆記裡，下一個流程就可能做出錯誤決定。

Cloudflare 的 Justin Joyce 看到的是另一種困難。傳統 GTM 團隊經常在 Excel、Google Sheets、CRM 和 dashboard 之間切換，dashboard 可以回答固定問題，卻很難回答每個業務正在面對的特殊情況。新人缺少資料與產業脈絡，資深業務則要把時間花在重複分析。這個問題讓 AI agent，也就是能根據目標自行執行多步驟工作的 AI，有機會進入 GTM 流程，但前提是 agent 必須理解公司的商業規則和資料定義。

所以，產生了 GTM engineering 這個概念，重點放在 CRM 之外的整體系統。Ramp 把它定義成，團隊先描述一個市場推進方案，再讓系統找出受眾、產生內容、啟動不同渠道，最後交給負責人審核；Notion 則把它寫成 Know、Decide、Act、Learn 的循環；Exa 直接把 GTM 當成資料問題。這些做法都在處理同一件事，如何把原本分散在不同部門和工具裡的工作，整理成可以被資料驅動、被 agent 執行、被人審核和被結果修正的流程。

Ramp 的做法很接近「從一個想法直接走到一套 GTM 行動」。分享裡的例子是找出美國東岸建築業、喜歡打高爾夫的目標客戶，再針對這群人準備 Pro V1 高爾夫球、主動開發流程、廣告文案、網站內容和產品內通知。團隊不用分別把這個想法交給行銷、業務、廣告和產品團隊處理，系統先把它組成一個完整方案，再由各渠道的負責人確認是否適合執行。

Ramp 認為，這套做法的基礎是 customer data platform，也就是把客戶、產品、CRM、公司資料、網站行為、購買訊號、募資、招聘、email、會議和通話紀錄放在一起的資料層。Ramp 會用即時事件、交易資料庫、資料倉庫與反向資料同步，把不同來源的資料送到需要使用它的流程。會前 brief 是一個具體例子，系統會整理參與者、職稱、會議目標、產品使用狀況、帳戶健康度、客戶 email 和未解決的 ticket。

Exa 的 Jeffrey Wang 將這個問題再往外延伸。Exa 需要建立一個持續更新的市場模型，裡面有客戶、人物、產品使用量等內部資料，也有公司、新聞、招聘、募資和技術棧等外部資料。Exa 會把公司描述轉成可比較的向量，替目標市場裡的公司分類，判斷它們屬於模型供應商、AI coding 平台或 GTM intelligence 等類別，再針對特定帳戶深入研究。這種做法讓 GTM 團隊處理整個市場，而不只是一份固定名單。

Exa 的 Request Lens 會把市場資料轉成可行動的提醒。當目標公司註冊、搜尋量突然增加、使用量下降，或重要帳戶出現在系統裡，團隊可以收到通知，再決定要不要研究、聯絡或調整客戶策略。這和固定每週匯出名單的差別，在於系統開始追蹤「什麼事情改變了」，而不只是保存「目前有哪些公司」。

Clay 的 Everett Berry 也把帳戶視為持續變動的市場 entity。公司可能被收購、換辦公室、推出新產品、增加招聘，聯絡人也可能離職或更換，因此 CRM 裡的帳戶狀態不能只在建立時填一次。Clay 使用 waterfall，讓多家資料供應商依序填補缺漏欄位，再用評估比較不同供應商的準確度，並依照欄位的變動速度選擇更新頻率。這些資料工作會直接影響 agent 是否找對人、寄對訊息和判斷對帳戶。

Clay 還提到 entity resolution，也就是確認不同系統裡的資料是否指向同一家公司或同一個人。如果這件事沒有做好，同一個人可能被當成兩個對象，Salesforce 和 Outreach 的同步也可能因為時間差而重複執行。對 GTM agent 來說，資料品質不只是欄位有沒有值，還包含資料來源、更新時間、可信程度，以及每個 entity 和其他記錄的關係。

Notion 的資料架構提供了另一個實作方向。Snowflake 負責計算 accounts、contacts、workspaces、eligibility 和 facts 等資料，DynamoDB 則提供低延遲的客戶 profile，同時保存研究摘要和其他生成內容。Notion 也把資料同步回熟悉的工作介面，讓團隊能在相同的資料基礎上研究帳戶、回答問題，再把任務送往 Nooks 或 Outreach。這樣的設計把資料計算、資料提供和團隊操作分開，讓每一層都能有清楚的責任。

Cloudflare 的做法是把公司的商業規則寫成 skill files，也就是 agent 可以依照執行的技能檔案。當業務問「為什麼成交日期或金額改變了」，agent 要先理解公司的成交定義、金額計算方式、區域劃分和時間範圍。Cloudflare 也建立集中管理的 skill repository，由 GTM 和營運團隊共同審查，避免每個部門各自建立一套互相衝突的規則。這些內容看起來不像 AI 功能，卻決定了 agent 能不能在同一套商業語言下工作。

有了資料和規則，下一個問題是什麼時候該行動。Notion 將 signal 定義成足以改變下一步的事件，例如使用者碰到 AI 使用上限、填寫 contact sales、公司開始招聘，或外部出現募資和技術棧變化。系統會先判斷行動和負責人，再建立人或 agent 的任務；沒有明確事件時，才使用預測模型推薦功能、生命週期 email 或產品內訊息。這讓 GTM 流程從固定排程，變成依照客戶狀態調整。

Cloudflare 採用的是「查詢、推送、自助」並行的方式。需要答案時，使用者可以讓 agent 查資料；需要團隊掌握狀況時，系統每週主動產生 business summary；需要建立新流程時，GTM 人員可以在 Cloudflare OS 裡產生 forecast brief、QBR 簡報、purchase deck、account plan、renewal 和 upsell 分析。這個內部工作空間建在 Workers 和 Durable Objects 上，重點是讓不同角色都能直接使用相同的資料和技能。

Cloudflare 的每週 summary 會經過多個 agent 處理。第一個 agent 產生草稿，第二個 agent 檢查資料正確性，第三個 agent 針對語氣、風險與機會重新整理，最後才推送給團隊。Cloudflare 報告整體效率約提升 2 倍，但也承認報價、審批和 Salesforce 寫入仍然很難放心自動化。這說明 GTM 的工作量可以由 agent 放大，但涉及對外承諾和正式資料寫入仍需要更嚴格的控制。

Ramp 把這種控制放進可恢復的工作流程裡。它使用 Temporal，把每個工具呼叫和模型呼叫記成可以重試的步驟；如果背景 worker 失敗，流程可以從中斷的地方繼續，不需要整個任務重新開始。夜間的背景 agent 可以替每個帳戶準備會議資料，遇到需要人工判斷的地方就暫停，等人補充資料或批准後再往下執行。這讓自動化從一次性的 prompt，變成可以長時間運作的工作流程。

Clay 的圖形化流程則把 agent、工具、條件判斷、程式碼和批次處理組成一個執行圖，再連到 CRM、資料倉庫、寄信工具、撥號工具、通話紀錄和 Slack。Clay 進一步提出每個帳戶各自擁有長時間運作的 agent，平時休眠，收到新的 signal 或固定檢查時間到來時再被喚醒。這種設計能持續累積帳戶脈絡，但也要求系統清楚區分哪些 CRM 欄位可以自動更新，哪些欄位必須由人或固定規則管理。

Notion 在這裡保留了更明確的人機邊界。Agent 可以研究帳戶、整理上下文、草擬 email、建立任務和推薦下一步，人則判斷內容是否正確、現在是否適合聯絡，以及這個行動是否會影響客戶關係。Notion 預設不讓 agent 直接和客戶聊天，sales-assist 的行動仍需要人批准。Notion 分享的早期結果是，加入客戶上下文的推薦，讓使用者採取下一步的機率提高 63%。

Clay 提醒，文案生成通常只佔 GTM agent 工作的一小段。錯誤的 CRM 同步、重複寄信、客戶已安排會議卻沒有停止其他活動、寄信網域信譽受損，都會直接影響商業結果。Ramp 也把報價、審批和 CRM 寫入列為較難自動化的區域。只要 agent 開始對外發送訊息，資料錯誤就不再只是內部回答品質問題，而會變成客戶體驗和收入風險。

Snowflake 的 Sait Izmit 從內部 GTM assistant 的部署經驗，說明了信任要怎麼建立。這套 assistant 已經服務超過 6,000 名使用者，每週約回答 40,000 個問題，累積超過 100 萬個問題。Snowflake 一開始先收集 150 個真實 sales 問題，初始正確率約 50%，因此先把回答範圍縮小，優先把少數高頻問題做到可信任，再逐步增加資料和能力。

Snowflake 採取先試用、再擴大的方式。團隊先讓 AI-native 使用者試用，再開放給約 10%、600 人的 beta 群組，觀察資料需求和每週留存，最後才全面推出。Sait Izmit 提到，初期只有約 20% 的人嘗試產品，因此他花了大量時間進入 sales meeting、做 demo、展示 dashboard，並請主管協助推動。這個案例說明，企業 agent 的導入包含產品設計、品質驗證、教育和管理支持，使用率本身不能直接代表產品成敗。

Snowflake 也接受系統需要持續重構。這套 assistant 的架構在演進過程中約有 80% 被重寫，團隊從長篇 agent instructions、Cortex Analyst 和 semantic views，逐步加入評估測試、routing、skill library、MCP、記憶、排程與 Slack 介面。團隊也把使用者問題分類，從真實問題裡找出功能缺口、資料缺口和品質問題。對一個每天處理數萬個問題的系統來說，問題紀錄本身就是產品設計的輸入。

Sourcegraph 的 Stephanie Jarmak 把這種評估往 agent 的使用體驗延伸。Sourcegraph 建立 CodeScaleBench，讓 agent 執行數百種軟體開發生命週期任務，比較有沒有 code-navigation MCP 時的成功率、錯誤、token 和延遲。MCP 是讓 agent 呼叫外部工具的介面協定。她舉例說，agent 把參數名稱搞錯後雖然能自行修正，卻浪費了一整輪工作。對 agent 來說，文件裡一個不清楚的參數名稱，就是 GTM 流程裡的額外摩擦。

Sourcegraph 也做了 GEO 測試。GEO 是讓 AI 搜尋更容易找到、理解與引用產品內容的方法。當問題是一般性的產品比較時，Sourcegraph 約有 65% 的推薦率；當問題改成「修改共用函式庫時常破壞下游服務，因為看不到所有使用者」這種具體痛點時，Sourcegraph 卻完全沒有被提到。Stephanie Jarmak 的判讀是，產品功能可能存在，網站內容卻沒有把產品和使用情境連起來。這個測試讓 AI 搜尋的曝光問題，從排名問題變成產品定位與內容證據問題。

Inth 的 Christopher Burns 把這件事做成產品文件策略。Inth 維護開源的 cookie consent library c15t，團隊從使用者問卷發現，Claude、ChatGPT、Codex 和 Gemini 開始成為重要的 inbound 來源。Burns 因此把 agent-facing discoverability，也就是讓 agent 找到並理解產品的能力，做成一套工具組，包括手寫的 llms.txt、sitemap、每頁 markdown、WebMCP、package docs 和 AGENTS.md。

Inth 的做法有一個很實用的細節。Burns 說，手寫約 40 行有用內容的 llms.txt，在他們的測試裡比自動產生 1,000 行雜訊更有價值；coding agent 常常會直接讀 repository 和 node_modules，不一定會開官方網站，所以把文件一起放進 package，再用 AGENTS.md 指示 agent 如何找到，反而能減少理解成本。他們報告在不同模型上接近節省 50% token，這些數字是講者分享的內部測試結果。

Exa 也從另一個角度處理 agent 的分發問題。Jeffrey Wang 認為內部與外部系統都應該先提供良好的 API，讓 agent 可以透過程式穩定存取資料，也減少對人工操作介面的依賴。Exa 的 GTM 團隊在 Slack 中使用多個 coding agent，業務可以讓 agent 研究帳戶和製作 demo；Jeffbot 則把 email 寫作風格和過去決策整理成可重複使用的個人工作方式。這表示分發對象已經多了一種，產品要進入 agent 的選擇和執行流程。

AI 也改變了企業買方的 GTM 節奏。Aliisa Rosenthal 以她早期參與 OpenAI 企業市場 GTM 的經驗說，ChatGPT 上線時沒有 SSO、NDA 和 invoice 等企業功能，OpenAI 在企業需求很強的情況下，約 9 個月後先推出 enterprise 版本，幾個月後再推出 self-serve。後來 self-serve 成長更快，也對 enterprise 方案形成影響。她回頭看，較好的順序可能是先讓 self-serve 使用者暴露產品缺口，再補上企業功能。

Rosenthal 也分享過一個 inbound 處理失敗。當時 4 名 sales rep 一天收到約 10,000 個 inbound，團隊沒有及時收集電話、寄出自動回覆或處理 waitlist，導致部分企業客戶等不到回應，最後選擇 Microsoft Copilot。她因此建議把帳戶研究、sequence 和 dialing 交給工具與 agent 協助，讓 sales rep 把時間留給已經具備資格、需要信任和判斷的對話。

她對企業採購流程的建議也很具體。企業可以把 trust portal、NDA、滲透測試文件和 AI 資安問卷做成可非同步取得的資料，降低買方等待時間；可以用 reference customer、部分資料評估、custom demo 或 opt-out clause 取代所有漫長 POC；價格則可以採用 base license 加 usage，並提供 spend cap。她分享 OpenAI 早期曾以每位使用者每月 60 美金設定 Enterprise 價格，後來調整計價方式，目標是降低客戶開始使用的阻力。

當研究、資料整理、草稿和基本執行都逐步自動化，人仍然會留在幾個位置。Notion 讓人批准高風險的 sales-assist 行動，Cloudflare 把報價和 CRM 寫入列為難題，Clay 關注寄信網域信譽和跨渠道停止發送規則，OpenAI 則認為高單價 enterprise deal 仍需要 demo、會議和客戶 champion 的信任。自動化讓人從重複工作移開，也讓人的責任更集中在客戶信任、價值判斷和關鍵承諾。

這也解釋了新角色為什麼會出現。Sourcegraph 把 DevRel 延伸成 Agent Advocate，工程負責介面、MCP 和評估，Product 負責完整 agent 體驗，Marketing 則追蹤產品是否被 agent 找到和推薦。Exa 的 GTM 團隊則由 FDE，也就是 Forward Deployed Engineer，直接進入客戶場域協助導入與維護 AI 系統；非 FDE 的 GTM 人員則學會使用這些系統。這個角色的價值，在於把客戶問題、資料、產品能力和工作流程接起來。

如果要把這些公司的做法轉成一套落地順序，我會先選一個可以驗證的工作流程。Snowflake 從 150 個真實 sales 問題開始，Ramp 先做單一團隊的會前 brief，Notion 先處理 cold outbound 和 sales-assist，這些案例都從明確任務開始。先把成功條件、資料來源、人工介入點和錯誤處理寫清楚，再增加其他帳戶與渠道，團隊才知道每一次擴張帶來了什麼。

接著要把上下文資料的責任寫清楚。Exa 把市場、客戶和決策資料放在一起，Clay 處理帳戶變化、供應商資料和 entity resolution，Cloudflare 把商業規則寫進 skill files，Notion 則在資料中保留 owner、時間戳和 eligibility。這些資料工作不一定會出現在產品 demo 裡，卻會決定 agent 的回答能不能被相信。

再來是把人工責任寫進流程。Notion 讓 agent 草擬但不直接對客戶行動，Ramp 讓工作流程在需要時暫停，Clay 將可自動更新的 CRM 欄位和人類管理的欄位分開，Cloudflare 對 CRM 寫入與審批保持保留。這些設計都先回答三個問題：agent 可以做什麼，必須停在哪裡，錯誤發生後誰負責。

最後是把評估和結果紀錄當成產品的一部分。Sourcegraph 用 agent friction、token、延遲和成功率評估文件與工具體驗，Snowflake 從真實問題找出品質缺口，Cloudflare 為每週 summary 加上事實檢查和模型觀測。當同一個問題重複出現時，Ramp、Cloudflare 和 Inth 的做法都指向同一個方向，把人工解法整理成可重用的 skill、自助流程或產品文件，讓下一個人可以自己完成。

從 Notion、Cloudflare、Exa、Ramp 和 Clay 的案例來看，GTM engineering 的競爭力會逐漸集中在四件事：公司是否掌握可信任的客戶上下文，是否能把上下文轉成正確訊號，是否有可靠的跨工具工作流程，以及是否把人的判斷和責任放在適合的位置。模型能力會持續變化，這四件事卻會在每一次 GTM 執行裡累積影響。

GTM 目前仍然很難，因為它同時牽涉市場判斷、資料品質、客戶關係、內部協作、工具整合和商業責任。Cloudflare、Exa、Notion、Ramp 和 Clay 的做法讓我看到，AI 的作用在於把困難的部分逐步寫進資料、流程、權限、評估和產品裡。當 agent 可以替團隊做更多研究、整理、草擬和執行，GTM 團隊要回答的問題也會變成：我們是否知道要讓什麼事情發生，以及怎麼證明它正在發生。

來源：

The Death of Developer Advocates, Stephanie Jarmak, Sourcegraph

https://www.youtube.com/watch?v=Lrw0jqBNaw0

How AI Agents Let GTM Teams Scale, Justin Joyce, Cloudflare

https://www.youtube.com/watch?v=Qw_tC68KKes

Knowledge Systems: The New GTM Stack, Jeffrey Wang, Exa

https://www.youtube.com/watch?v=6pbQgnJ9Voc

How We Got LLMs to Recommend Our Open Source Library, Christopher Burns, Inth

https://www.youtube.com/watch?v=V_5bn4q-vAI

Building GTM AI Agents: Lessons from Deploying to 6,000 Users, Sait Izmit, Snowflake

https://www.youtube.com/watch?v=DrTdD-ttjCY

The Building Blocks of GTM Orchestration, Ramp