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 之前，以及任何序列激活之前。一旦联系人在活跃序列中，移除它们需要在活动进行中进行人工干预，届时退信可能已经发生。
从来源收集列表
→ 规范化并去重
→ 使用 BillionVerify 验证
→ 按信号应用路由决策
→ 将已审批记录导入 Close CRM
→ 将已验证联系人加入 Close 序列
CRM 迁移需要特别注意。将联系人数据从一个 CRM 迁移到 Close 时，往往会出现从未被验证过的联系人、多年未活跃的联系人，或来自已不再反映当前邮件状态的数据来源的记录。应在迁移完成前而非首个序列运行后进行验证。
Close 导入前路由每条结果。
| BillionVerify 结果 | 操作 |
|---|---|
| 有效 | 导入 Close 并加入目标序列 |
| 无效 | 不导入——添加至全局抑制列表 |
| Catch-all | 使用较低发量和更密切监控的独立序列 |
| 基于角色 | 使用适合共享收件箱的消息内容的独立序列 |
| 未知 | 保留待人工审核——不加入活跃序列 |
| 风险或一次性 | 不导入 |
维护一个覆盖所有 Close 序列的抑制文件。从一个序列中退信或退订的地址，不应通过不同的导入或新的序列注册再次进入。即使联系人记录仍然存在，Close 也不会自动阻止联系人进入新序列。
列表验证后的操作。
已验证联系人导入 Close 后：
- 有效联系人按标准节奏加入主要序列
- Catch-all 联系人在单独监控的低发量序列中运行
- 基于角色的联系人接收适合共享或团队收件箱场景的消息内容
- 无效和风险联系人被抑制，排除在所有未来序列注册之外
- 未知联系人在审核队列中等待任何序列决策
被抑制地址的 CRM 记录应更新以反映其状态，防止在创建新序列或应用不带抑制检查的智能视图过滤器时，同一地址被重新注册。
其他面临类似导入前决策的发件工具。
Instantly 邮件验证
在将名单导入 Instantly 活动和预热序列之前，先完成验证。
GMass 邮件验证
在 GMass 通过 Gmail 发送前，清洗 Google Sheets 列表。
Smartlead 邮件验证
为大批量 Smartlead 活动设置导入前的质量门控。
Lemlist 邮件验证
在 Lemlist 多渠道活动启动前验证名单，避免数据增强成为负担。
Salesloft 邮件验证
在记录进入 Salesloft 序列前，设置导入前的质量门控。
Outreach 邮件验证
在 Outreach 序列注册前验证邮件，保护企业发件人声誉。
Mailshake 邮件验证
在 Mailshake 活动前清洗名单，为小型外向团队维持低退信率。
Reply.io 邮件验证
在 Reply.io 序列前验证邮件，防止无效记录进入自动化工作流。
Mailmeteor 邮件验证
在 Mailmeteor 发送 Gmail 合并活动前，检查 Google Sheets 联系人。
QuickMail 邮件验证
在联系人进入 QuickMail 收件箱前，设置导入前的质量门控。
Saleshandy 邮件验证
在 Saleshandy 活动前验证名单，在较低发送预算下保护送达率。
Woodpecker 邮件验证
为 Woodpecker 活动和代理商客户设置导入前的验证步骤。
Klenty 邮件验证
在 Klenty 节奏启动前验证邮件，保持 CRM 来源联系人的数据质量。
Yesware 邮件验证
在基于 Gmail 的 Yesware 活动前验证名单，降低退信风险。
Overloop 邮件验证
在联系人进入 Overloop 序列前，设置发送前的质量门控。
Mixmax 邮件验证
在 Mixmax Gmail 序列前验证邮件，防止退信损害。
Lavender + BillionVerify 工作流
在 Lavender 协助撰写邮件前先验证名单，干净的数据能提升 AI 定向效果。
PersistIQ 邮件验证
在 PersistIQ 活动前检查名单，让 SDR 工作流远离无效联系人。
Autoklose 邮件验证
在 Autoklose 序列前验证邮件，保护自动发送免受名单风险影响。
SendBuzz 邮件验证
在 SendBuzz 活动前设置导入门控，大规模发送时维持低退信率。
Close CRM 邮件验证常见问题。
Close 在序列注册前会验证邮件地址吗？
Close 在联系人进入序列之前不会执行专用的外部验证步骤。序列注册基于联系人属性和智能视图过滤器，而非发送前的可投递性检查。BillionVerify 在联系人导入之前添加了这个质量关卡。
我在 Close 中已有数千个联系人，需要验证吗？
任何你计划加入序列的联系人都应该先验证——尤其是超过 90 天前添加的联系人，或来自 CRM 迁移的联系人。在 Close 中没有近期活动记录的联系人，是数据过期的最高风险来源。
Close 的 CRM 模式如何影响验证方式？
由于 Close 既是 CRM 又是发件工具，联系人数据问题会产生叠加效应。一次退信发送同时创造了一条低质量联系人记录和一次声誉打击。导入前验证同时保护了两者——你不仅在保护可投递性，还在保护联系人数据库的完整性。
联系人在 Close 中产生退信后会怎样？
Close 中的退信会损害发送域名声誉，并在 CRM 中留下可能被重新加入未来序列的记录。你应该将退信联系人标记为已抑制，更新联系人记录，并将该地址排除在所有未来序列注册之外。导入前验证可以防止大多数此类情况发生。
我应该在 CRM 迁移到 Close 之前验证联系人吗？
应该。CRM 迁移会带入源系统中的所有内容——包括多年前添加的联系人、无效地址、重复记录以及之前所有者的记录。在导入 Close 之前而非迁移完成后验证导出数据，不要等到序列已经在运行时才处理。