Close 同時管理序列和 CRM，不良記錄會同時損害兩者。
Close 是專為外向銷售團隊打造的 CRM，在單一介面中整合了聯絡人管理、電話和電子郵件序列。這種統一模式非常高效，但也帶來了複合風險：一筆不良電子郵件記錄不只影響一個活動，它留在 CRM 中，可以被加入未來的序列、匯入其他工具，並計入管道資料，直到有人主動移除它。
當聯絡人在 Close 中退信時，損害是雙重的：發送網域的聲譽受損，而 CRM 聯絡記錄現在成了需要清理的骯髒資料。使用 Close 的銷售團隊往往無法將「CRM 衛生」工作與「發送健康」工作分開，因為這本質上是同一個問題。
在 Close 序列執行前驗證，不只是為了保護投遞率，也是為了確保聯絡資料庫在記錄進入的那一刻起就保持準確。
Close 序列執行前應檢查什麼。
Close 聯絡人來自多個來源 — 手動輸入、CSV 匯入、CRM 遷移、潛客豐富化和 API 整合。每個來源的風險狀況各不相同。任何聯絡人進入序列前，都應檢查這些欄位。
| 欄位 | 重要性 |
|---|---|
| 電子郵件 | 進入序列的地址 — 需要有效且可投遞 |
| 網域 | 決定 catch-all 狀態、MX 有效性及公司網域是否仍活躍 |
| 來源 | CSV 匯入、API 同步、手動輸入、從其他 CRM 遷移 — 過期程度因來源而異 |
| 抑制狀態 | 先前退信和取消訂閱應在序列加入前標記 |
| 名單年齡 | 超過 90 天前加入 Close 的聯絡人，應在序列加入前重新驗證 |
每種訊號類型帶來的風險。
Close 中的序列加入通常由智慧視圖或篩選的聯絡人清單驅動。了解每種訊號類型對你的活動有何影響，有助於在加入序列前建立正確的篩選規則。
| 訊號 | 投遞行為 | 對 Close 序列的風險 |
|---|---|---|
| 無效 | 永久被拒絕 | 硬退信 — 對你的發送網域造成聲譽損害 |
| Catch-all | 網域接受所有地址，具體信箱不確定 | 不確定的投遞 — 增加退信風險並扭曲序列績效 |
| 基於角色 | 共用收件箱（info@、sales@、hello@） | 低互動，可能引發投訴，非具名個人聯絡人 |
| 一次性 | 臨時或低信任地址 | 非真實業務聯絡人 — 匯入前移除 |
| 未知 | 驗證結果不確定 | 透過人工審查解決前排除序列 |
| 重複 | 同一地址被加入多個序列 | 重複發送，投訴風險增加，活動資料扭曲 |
在匯入前驗證，而非退信後才驗證。
正確的驗證時機是在聯絡人匯入 Close 之前、任何序列啟動之前。一旦聯絡人在活躍序列中，在活動中途移除它們需要人工干預，而退信很可能已經發生了。
CRM 遷移需要特別注意。將聯絡資料從一個 CRM 移到 Close，往往會暴露從未驗證過的聯絡人、數年未活躍的記錄，或是透過不再反映當前電子郵件狀態的資料來源新增的記錄。應在遷移完成之前驗證，而非在第一個序列執行後才驗證。
在 Close 看到記錄前路由每個結果。
| BillionVerify 結果 | 行動 |
|---|---|
| 有效 | 匯入 Close 並加入目標序列 |
| 無效 | 不匯入 — 加入全域抑制名單 |
| Catch-all | 獨立序列，較低的量並更密切的監控 |
| 基於角色 | 獨立序列，帶有適合共用收件箱的訊息 |
| 未知 | 待人工審查 — 不加入活躍序列 |
| 高風險或一次性 | 不匯入 |
在你所有 Close 序列中維護一份跨越整體的抑制文件。從一個序列退信或取消訂閱的地址，不應透過不同匯入或新序列加入重新進入。Close 不會自動阻止聯絡記錄仍存在的聯絡人進入新序列。
名單驗證完成後。
已驗證聯絡人進入 Close 後：
- 有效聯絡人以標準頻率加入主要序列
- Catch-all 聯絡人在獨立監控的低量序列中執行
- 基於角色的聯絡人收到適合共用或團隊收件箱情境的訊息
- 無效和高風險聯絡人被抑制，排除在所有未來序列加入之外
- 未知聯絡人在任何序列決策之前在審查佇列中等待
被抑制地址的 CRM 記錄應更新以反映其狀態，這可防止當新序列建立或在沒有抑制檢查的情況下套用智慧視圖篩選時，同一地址被重新加入。