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 记录应更新以反映其状态，防止在创建新序列或应用不带抑制检查的智能视图过滤器时，同一地址被重新注册。