Klenty 运行发送序列。进入序列内容的质量由你决定。
Klenty 是为销售参与而构建的——与 CRM 同步的联系人、多步骤邮件序列、规模化个性化以及整个出站技术栈的工作流程自动化。它与 Salesforce、HubSpot 和 Pipedrive 紧密集成，这意味着联系人通常直接从 CRM 同步流入活跃序列。
这种紧密集成很高效，也是一个风险向量。CRM 记录随时间积累。18 个月前添加的联系人可能已经换了工作、域名过期，或者完全离开了一个组织。当这些事情发生时，他们的邮件地址不会自动从 CRM 中消失。当 Klenty 同步这些记录并将它们放入序列时，名单质量问题就变成了实时发送问题。
Klenty 不对每个联系人是否应该收到外推做出最终决定。这个判断属于上游——在名单到达序列引擎之前。
Klenty 导入前应检查的内容。
进入 Klenty 的每个名单在导入前都应经过字段级检查。CRM 同步名单需要特别注意，因为每条记录的年龄和来源通常不明确。
| 字段 | 为何重要 |
|---|---|
| 邮件 | 进入序列的地址——需要有效且可投递 |
| 域名 | 决定 catch-all 状态、MX 记录有效性，以及公司是否仍然活跃 |
| 来源 | Salesforce 同步、HubSpot 导出、Pipedrive、手动上传——每种来源的陈旧风险不同 |
| 抑制状态 | 在之前活动中退信或退订的联系人不应通过 CRM 同步重新进入 |
| 名单年龄 | 超过 90 天前添加到 CRM 的任何记录在序列注册前都值得重新验证 |
每种信号类型产生的风险。
信号类型在 Klenty 看到名单之前就很重要。了解每种结果的含义，有助于你在任何联系人进入序列之前应用正确的路由规则。
| 信号 | 投递行为 | 对 Klenty 序列的风险 |
|---|---|---|
| 无效 | 在服务器端永久拒绝 | 硬退信——直接损害发送域名声誉 |
| Catch-all | 域名接受所有地址，单个邮箱不确定 | 可能投递或退信——在序列指标中放大不确定性 |
| 角色型 | 共享收件箱（info@、sales@、support@） | 技术上有效，但不是命名外推目标——低参与度、潜在投诉 |
| 一次性 | 临时或低信任地址 | 不是真实的商业联系人——导入前移除 |
| 未知 | 验证结果不确定 | 未经额外审查不应进入高发量序列 |
| 重复 | 同一地址多次出现 | 跨序列步骤重复发送，增加投诉风险 |
在导入前验证——而非在退信后。
正确的干预点是在将联系人导入 Klenty 之前。一旦联系人进入活跃序列，他们会自动推进各步骤。在序列运行中途停下来移除坏记录既有破坏性，又往往为时已晚——退信已经发生，声誉损害已经开始。
Klenty 中的 CRM 同步功能不应用外部质量门控。它带入 CRM 中有的内容。BillionVerify 位于 CRM 导出和 Klenty 导入之间——不在 Klenty 本身内部。
在 Klenty 看到它之前路由每个结果。
| BillionVerify 结果 | 行动 |
|---|---|
| 有效 | 导入 Klenty 并注册到目标序列 |
| 无效 | 不导入——添加到抑制名单 |
| Catch-all | 单独的低发量序列，或发送前先数据丰富 |
| 角色型 | 包含适合共享收件箱消息的单独序列 |
| 未知 | 保留以供人工审查——从高发量序列注册中排除 |
| 高风险或一次性 | 不导入 |
跨 CRM 同步维护最新的抑制文件。如果 Klenty 自动从你的 CRM 同步新联系人，在他们进入任何活跃序列之前对这些新记录运行验证检查。同步不知道地址是否陈旧。
名单验证后的处理。
经过验证的联系人导入 Klenty 后：
- 有效地址按你的标准步骤节奏注册到目标序列
- Catch-all 地址在单独监控的低发量序列中运行
- 角色型地址获得不假设有命名读者的序列消息
- 无效和高风险地址被抑制并从未来 CRM 同步中排除
- 未知地址在做出任何序列决定之前等待审查队列
BillionVerify 不直接连接到 Klenty。它在导入前处理你的名单并返回分类输出。你应用路由规则，然后导入已批准的分类。