Apollo.io 中文實戰指南：從 ICP 搜索到 Sequence 與 CRM 閉環

圖：ImageGen 生成的主題封面，不是 Apollo 官方界面；視覺元素概括篩選、驗證、Sequence 與 CRM 寫入鏈路。

最後更新：2026 年 8 月 24 日
適合人群：B2B 增長、銷售開發（SDR/BDR）、銷售運營與 RevOps 團隊
閱讀目標：先完成一份已去重、已分配負責人的小規模試驗名單，再設計分層、外聯和 CRM 規則。

Apollo.io 把公司/人員搜索、數據豐富、評分、列表、Sequence 和 CRM 同步連接在一起。真正有效的起點不是“能導出多少聯繫人”，而是能否把一個 ICP 寫成可複用的篩選配方，並讓團隊清楚回答：為什麼是這家公司、為什麼是這個人、為什麼現在聯繫、什麼時候必須停止。

本文先幫助你在 15 分鐘內得到第一份可審查名單，再逐步進入 A/B/C 分層、14 天 Sequence、字段衝突和合規治理。Apollo 中的郵箱、電話、任職和信號可能過時或不完整，平臺記錄也不代表當事人已同意接收營銷；在任何實際觸達前，都要執行文末的適用法律和組織政策檢查。

15 分鐘快速上手

這 15 分鐘只做“名單研究”，不連接生產郵箱、不啟動 Sequence，也不打開全量 CRM 同步。

建議首輪只保留 20 家公司，每家公司 1–2 個角色。輸出表至少有：公司、域名、聯繫人、角色、ICP 證據、觸發信號、Owner、禁止聯繫狀態、下一步。數量不是成功標準；可解釋且可複查才是。

Apollo.io 能解決什麼問題

Apollo 可以提高研究和執行效率，但不能替代人工驗證、銷售判斷、發件信譽管理或法律合規審查。

界面指引：People、Companies 與篩選邏輯

圖：教學界面示意、示例數據、非官方實時截圖。篩選器名稱、入口位置和可用字段會隨套餐、地區與產品更新變化；以當前賬號為準。

搜索入口

1. 啟動 Apollo，進入 People 或 Companies；
2. 點擊 Show Filters → More Filters 查看完整篩選器；
3. 選擇條件並點擊 Apply filters；結果會隨篩選變更；
4. 複核 Total、Net New 與 Saved 的口徑；
5. 條件穩定後點擊 Save as new search，記錄名稱、負責人和版本日期。

Apollo 官方當前的篩選說明指出：不同篩選器之間使用 AND，同一篩選器內多個值使用 OR。例如，員工數 51–200 與美國地區同時啟用，記錄必須同時滿足；在職位篩選中加入 Director 與 VP，則可以滿足其中一個。官方還提示搜索最多顯示 100 頁，達到上限通常說明條件太寬，應增加 ICP 條件，而不是繼續翻頁。查看 Search Filters Glossary

Total、Net New 與 Saved

“無結果”不一定表示市場不存在。先一次移除一個條件，找出過窄環節；同時切到 Saved 檢查符合對象是否已被團隊保存。

把 ICP 寫成一條可複用搜索配方

ICP 是公司層，Persona 是人層。先建立公司池，再在公司內找購買者、業務負責人和使用者，通常比在全庫直接搜職位更穩定。

示例配方：北美客戶支持自動化 SaaS

假設你銷售一款面向中型 SaaS 的客戶支持自動化產品，首輪配方可以寫成：

Companies Search

• 公司總部：United States 或 Canada；
• 員工數：51–200；
• 行業/關鍵詞：Software、SaaS、B2B（根據實際結果校正，不把標籤當絕對事實）；
• 技術：使用 HubSpot、Zendesk 或 Intercom 中至少一種；
• 信號：近階段客服/客戶成功團隊招聘或員工增長，可作為加分，不作為唯一入選條件；
• 排除：現有客戶、開放機會、競爭對手、學生/社區、無法服務地區、內部域名。

People Search

• Department / Job function：Customer Success、Support、Operations；
• Management level：Director、VP；
• Job titles：Director of Customer Support、VP Customer Success、Head of Support 等相近稱謂；
• Email status：優先已驗證，但仍需實際發送前檢查；
• 每公司人數：1–2 人，避免同一賬號多人同時收到近似信息。

輸出規則

• 公司域名為去重主鍵，CRM ID 存在時優先使用 CRM ID；
• 聯繫人必須有 Owner；沒有 Owner 的記錄不進入 Sequence；
• 已退訂、Do Not Contact、DNC、已明確拒絕和現有活躍機會直接排除；
• 每週抽查 10% 記錄，若誤入率超過 20%，回退調整篩選器。

先強條件，後信號

強條件回答“是不是目標客戶”：地區、規模、業務模式、角色。信號回答“是不是更值得現在研究”：招聘、融資、增長、職位變化、網站訪問等。不要用一個時機信號覆蓋明顯的公司或角色不匹配。

工作流總覽：從公司池到 CRM

圖：原創教學流程。先小批量驗證，再進入 Sequence 和 CRM；任一否決項都應讓記錄退出自動化流程。

一條穩定鏈路是：ICP 配方 → Companies → People → 人工抽查 → 去重/Owner → A/B/C → Sequence → CRM → 結果覆盤。任何團隊都應在“加入 Sequence”和“開啟 CRM 寫入”前設置人工審批點。

工作流一：建立公司池與目標角色

步驟 1：從 Companies Search 開始

先應用 3–5 個強條件：可服務地區、員工規模/階段、行業或關鍵詞、關鍵技術、明確排除列表。結果仍超過可審查量級時，不要機械增加隨機條件；應回到 ICP，選擇能解釋購買可能性的條件。

Industry 通常較寬，Keywords 更細但噪聲更高。兩者一起使用後要抽查公司網站，避免公司描述偶然出現某個詞而被誤納入。

步驟 2：在公司內選擇 1–3 個角色

角色應覆蓋三類關係：

• 經濟買方：能批准預算或改變優先級；
• 業務負責人：對問題和結果負責；
• 實際使用者/影響者：最清楚現有流程與阻力。

組合 Job titles、Management level、Department/Job function 與聯繫人 Location。公司總部與聯繫人所在地是兩種口徑，跨境場景必須分開核查。

步驟 3：把排除項固化

至少排除：現有客戶、活躍機會、已退訂/拒絕聯繫、DNC/Do Not Contact、競爭對手、內部域名、個人郵箱、不服務地區、無關職能、已在同類 Sequence 的對象。

排除項要由 RevOps 維護為共享 List 或 CRM 條件，不要依賴每位 SDR 記憶。

步驟 4：保存搜索，而不是隻保存一次結果

搜索條件穩定後 Save as new search。名稱建議為：市場-規模-產品線-角色-v日期，例如 NA-51_200-CSAuto-CSLeaders-v20260824。同時記錄預期量級和抽查通過率，便於下一次發現數據分佈異常。

工作流二：保存、驗證與 A/B/C 分層

保存前的五項檢查

1. 公司網站、規模和業務模式是否仍符合 ICP；
2. 聯繫人是否仍在職，角色是否與問題相關；
3. 郵箱/電話狀態與數據更新時間是否可接受；
4. Apollo 和 CRM 是否已存在同一公司、聯繫人或活躍機會；
5. Owner、退訂、Do Not Contact 和 DNC 狀態是否完整。

Email status 為 verified 只表示數據質量狀態，不代表必達，更不代表已同意營銷。

100 分自定義標尺

這套 100 分標尺是團隊示例，不是 Apollo 官方 Score。若使用 Apollo Scores，應查看具體 filters 和 signals 的貢獻，確保高分能夠解釋；高分名單會議率持續偏低時，應先修正 ICP 和權重。

A/B/C 閾值

• A 層：80–100 分，且時機信號至少 10 分。 每家公司 1–2 人，人工研究，首觸達深度個性化；
• B 層：65–79 分，或 80 分以上但缺少明確時機。 半個性化、小批量 Sequence；
• C 層：低於 65 分或關鍵信息缺失。 進入培育、補數據或暫緩，不直接批量發送；
• 排除層：命中任何否決項。 不進入外聯，寫回原因並同步抑制狀態。

工作流三：設計 14 天 Sequence

Apollo 官方文檔將 Sequence 定義為在計劃週期內按順序執行郵件、電話、社交互動和任務等觸點的外聯活動。當前創建入口是 Sequences → Create Sequence，可從 AI-assisted、Template、Clone 或 From scratch 開始；保存後應檢查 Settings 中的名稱、標籤、Owner、發送日程和 ruleset，再逐步啟用步驟。查看 Create a Sequence

圖：原創教學序列，示例觸點、時間與退出條件並非 Apollo 官方推薦值；使用前應按客單價、週期、地區規則與歷史數據校準。

先寫退出條件，再寫文案

以下事件任一發生，就停止或人工複核：

• 收到真人回覆，不論正向或負向；
• 退訂、投訴、硬退信或明確拒絕；
• 命中 Do Not Contact、DNC 或內部抑制名單；
• 會議已預約、機會已創建或已有 Owner 正在跟進；
• 聯繫人離職、公司不再適配或數據可信度不足；
• 同一公司已有另一聯繫人積極互動。

14 天保守節奏示例

Apollo 官方說明自動郵件無需人工任務即可發送；手動郵件、電話、LinkedIn 和 action item 等步驟會創建任務，未完成或未跳過的必需任務可能阻止聯繫人繼續前進。上線前用 Preview 和測試郵件檢查變量、簽名、時區、鏈接與退出說明。

每日與每週監控

• 每日：硬退信、投訴、退訂、發送錯誤和積壓任務；
• 每週：正向回覆、有效會議、機會和不合格原因；
• 打開率只作診斷輔助，受隱私保護和圖片代理影響；
• 退信或投訴突然升高時，立即暫停相關批次，檢查名單、認證、郵箱信譽、頻率和文案。

工作流四：CRM 字段映射與衝突處理

CRM 集成不是“連接後自動更乾淨”。先決定哪套系統擁有哪類字段，再決定 Apollo 何時創建、填充或覆蓋。

官方入口與上線順序

Apollo 當前官方說明：連接 Salesforce、HubSpot、Pipedrive 或 Zoho 後會自動映射聯繫人/賬戶字段；可在 Settings → Objects, fields, stages → Contact fields & stages / Account fields & stages → Fields 查看和調整。若 CRM 字段沒有對應 Apollo 字段，映射過程可能創建自定義字段，因此管理員應先審查字段模型，而不是直接全量開啟。查看推薦字段映射

建議順序：

1. 指定聯繫人、公司、機會各自的記錄主系統；
2. 定義唯一鍵：聯繫人優先 CRM ID/業務郵箱，公司優先 CRM ID/規範化域名；
3. 列出必須映射字段及數據類型；
4. 設置空值填充、已有值覆蓋和衝突進入人工隊列的規則；
5. 在沙盒或 10–20 條記錄上測試創建、更新、合併、刪除和退訂同步；
6. 保存測試結果和回滾方式，由管理員批准後再擴大。

字段衝突處理示例

字段衝突應有 Owner、處理時限和日誌。不要讓“最新時間戳”自動覆蓋所有業務字段；數據新不等於業務正確。

完整案例：從 183 家公司到 20 個試驗賬號

以下公司名與數值均為教學示例。

一家客戶支持自動化 SaaS“Northstar CX”要測試北美 51–200 人 B2B SaaS 市場。

第一步：公司池

團隊應用總部、員工數、行業/關鍵詞和技術條件，得到 183 家公司。隨後排除 21 家現有客戶/活躍機會、14 家不服務地區或業務不符公司，並隨機抽查 20 家；4 家因描述關鍵詞誤入，於是收緊 B2B 與客服技術條件，剩 96 家。

第二步：人員層

在 96 家公司中篩 Customer Success、Support、Operations 的 Director/VP/Head，限制每公司最多 2 人，得到 142 個聯繫人。核驗職位、公司網站和 Owner 後，留下 118 個有效候選。

第三步：分層

第四步：首輪 Sequence 與結果定義

20 個 A 層賬號先按 14 天節奏運行，每家公司只聯繫 1 人。團隊預先定義：有效正向回覆、有效會議、機會、硬退信、退訂/投訴是核心結果；自動回覆與不在職回覆單獨分類。無論結果好壞，都回寫“為什麼合格/不合格”，用於下輪調整 ICP，而不是立刻擴大名單。

合規、發件與數據治理門檻

這一節應由法務、隱私、IT/安全和 RevOps 一起確認。本文不構成法律意見；實際義務取決於目標地區、渠道、關係性質和組織政策。

外聯前最低檢查

• 明確數據用途、合法處理依據和適用的隱私/電子通信規則；
• 區分公司所在地、聯繫人所在地與發件主體所在地；
• 執行內部禁止聯繫、Do Not Contact、DNC、退訂和已有客戶/機會檢查；
• 提供真實發件身份、必要披露與可執行的退出機制；
• 建立數據保留、訪問、糾正、刪除和審計流程；
• 電話、短信、社交等渠道按各自規則單獨審批；
• 對 GDPR、CCPA/CPRA、CAN-SPAM、CASL、PECR 或當地電信規則適用的場景，由專業負責人確認。

權限與發件保護

• 只有獲授權人員可以連接郵箱、創建/激活 Sequence、導出、連接 CRM 和修改字段映射；
• 生產郵箱使用統一的域名認證、發送上限、時區、簽名和退訂配置；
• 新郵箱/域名循序建立信譽，不用突然放量“測試上限”；
• 共享賬號不連接生產郵箱、CRM、通訊錄或客戶數據；
• 投訴、硬退信、退訂異常是暫停信號，不是需要隱藏的指標。

套餐、Credits 與 RelayX 訪問邊界

高級篩選、Signals、Scores、郵箱/電話揭示、導出、Sequence、意圖、CRM 集成與 credits 會因 Apollo 套餐變化。Net New 記錄的保存、揭示或加入 Sequence 可能觸發不同 credits 規則；不要把本文中的工作流當作固定計費說明。採購前用一個真實 ICP 測試篩選器、數據覆蓋、去重、導出、Sequence 和 CRM 需求，並以官方定價與賬號 Usage 為準。

RelayX 共享訪問只用於低敏感度研究：不連接生產郵箱/CRM，不保存客戶機密、內部名單或個人敏感數據，不用共享身份執行大規模外聯。站內入口見營銷增長方案與Apollo.io 工具頁，實際權益、credits 與可用功能以交付頁面為準。

常見誤區與排錯

30 天落地計劃

第 1 周：配方與治理

• 定義一個 ICP、Persona、否決項和 Owner 規則；
• 建字段字典、唯一鍵與退訂/DNC 同步規則；
• 完成權限、地區與渠道合規審查；
• 不連接生產系統，先使用測試數據。

第 2 周：名單與評分

• 建立 Companies Search 與 People Search；
• 抽查至少 50 條記錄並記錄誤入原因；
• 保存搜索，建立 A/B/C 閾值；
• 形成 20 個已去重、已分配 Owner 的 A 層賬號。

第 3 周：小批量 Sequence

• 創建 14 天 Sequence 和明確退出條件；
• 只啟用一個細分市場、一個主要變量測試；
• 每日監控退信、投訴、退訂和積壓任務；
• 按正向、負向、不合格、自動回覆分類。

第 4 周：CRM 與覆盤

• 在沙盒/小範圍測試字段創建、更新與衝突；
• 計算正向回覆、有效會議和機會，不只看打開率；
• 根據不合格原因調整 ICP 與評分；
• 穩定後再申請擴大範圍，保留回滾和審計日誌。

常見問題

Apollo 的聯繫人可以直接群發嗎？

不應僅因數據存在就群發。需要驗證相關性、數據狀態、適用地區規則、組織政策、退訂/DNC、發件信譽、頻率和合理目的。

Score 高就應該進入 Sequence 嗎？

不一定。Score 只代表配置條件和信號的匹配程度。還要檢查角色、數據有效性、已有關係、合規狀態和是否有足夠的聯繫理由。

先連接 CRM 還是先做搜索？

先用小規模搜索驗證 ICP 和去重邏輯，再設計字段模型，在沙盒或有限記錄中測試同步。不要在規則未明確時開啟全量雙向寫入。

Sequence 應該有多少觸點？

沒有通用最優數。本文的 5 個觸點只是保守示例。應根據受眾、渠道、法律要求、客單價和歷史反饋調整；投訴、退訂和負向回覆升高時應減少或暫停，而不是繼續加觸點。

共享賬號可以連接郵箱或 CRM 嗎？

不建議。連接生產系統會暴露客戶數據、授權和發送能力，也可能造成不可控寫入。應使用受控的官方團隊賬號和最小權限。

參考資料

• RelayX：營銷增長方案
• RelayX：Apollo.io 工具詳情
• Apollo：Search Filters Glossary
• Apollo：Create a Sequence
• Apollo：Recommended Field Mapping
• Apollo：Save Contacts and Accounts
• Apollo：Scores Overview
• Apollo：Use a Score Filter
• Apollo：Add Contacts to a Sequence
• Apollo：Integrate HubSpot with Apollo
• Apollo 官方定價

本文為原創整理，並結合截至 2026 年 8 月 24 日可訪問的 Apollo 官方資料重新組織。教學配圖中的界面和數值均為示意，不代表 Apollo 官方實時界面；篩選器、套餐、credits、評分、集成和發送能力以官方實時頁面及實際賬號權限為準。任何實際外聯都應依據目標地區和組織政策完成專業合規審查。