联系方式获取记录表：证据、状态、去重与发送前治理
联系方式表不是“邮箱名单”，而是账户证据的一部分
如果表格只保存姓名、邮箱和电话，它很快会变成无法解释来源、无法判断是否仍有效、也无法安全交接的名单。尤其在海关数据开发中，公司名、集团官网、地区子公司、品牌站和个人主页可能属于不同主体；错误地合并一次，就会让后续多人对同一个不相关地址重复触达。
一张合格的联系方式获取记录表应把账户、联系人/入口、证据、状态和行动连接起来。它的任务不是最大化地址数量，而是回答：这是谁的公开业务入口？为什么与当前账户和目标产品有关？现在是否允许由谁以什么渠道做哪一步？若答案不清楚，记录应停留在待核或观察，而不是导出发送。
用“账户—入口”两层结构，避免把公司与个人混在一行
先建立账户主表，再建立可有多行的入口表。账户主表保存标准实体、官网、产品和队列；入口表保存每个公开邮箱、表单、电话或个人公开主页。不要把同一公司多个邮箱塞进一个单元格，也不要用“采购联系人”覆盖通用邮箱、表单和真实人员的差别。
| 表层 | 一行代表什么 | 必填事实 | 不应写入 |
|---|---|---|---|
| 账户主表 | 一个已标准化的企业/业务单元 | 标准实体、国家/地区、官网、产品族、账户状态 | 未核验的集团关系、采购猜测 |
| 入口表 | 一个邮箱/表单/电话/公开角色 | 入口类型、来源、用途、状态、核验日 | “应该是采购人”等无依据判断 |
| 动作日志 | 一次具体研究或沟通行为 | 日期、渠道、内容摘要、结果、下次动作 | 未记录的批量动作或私密内容 |
| 排除/停止表 | 不应再使用的记录 | 原因、日期、适用范围、重开条件 | 直接删除导致历史丢失 |
账户 ID 必须稳定。即使公司改名、网址跳转或新增联系人，也不要另起一套无关联记录；但未证实的同名主体也绝不能共用 ID。
账户主表的最低字段
| 字段 | 为什么需要 | 示例状态/规则 |
|---|---|---|
| account_id / 标准实体 | 让所有入口回到正确账户 | 名称变体放别名字段，不覆盖原名 |
| 国家、地区、业务单元 | 排除同名与集团错配 | 未确认则标待核，不猜城市 |
| 官网与归属状态 | 判断官方入口是否可信 | 已确认 / 候选待证 / 未找到 |
| 目标产品族与业务模式 | 判断入口/角色是否相关 | 只记录已定义的产品族规则 |
| 数据范围与账户队列 | 防止 C/U/D 账户被直接外联 | A/B/C/U/D 与复核日并存 |
| 风险与停止标记 | 防止拒绝、主体冲突回流 | 明确禁止导出时为硬过滤 |
主表不是联系人资料的复制品。它负责规定“这个账户现在是否值得补全、补全的目的是什么”，入口表才负责记录渠道细节。
入口表字段：来源、用途、证据与状态缺一不可
account_id / 入口 ID / 入口类型（官方邮箱、表单、总机、公开角色、目录线索）
显示名称或地址 / 域名或 URL / 国家地区 / 官方页面用途
来源 URL / 发现日期 / 最后核验日期 / 证据截图或备注位置
E 状态（地址/入口）/ R 状态（角色）/ P 状态（入口路径）
主体支持、业务相关依据、冲突与未知
触达资格：允许 / 需确认 / 禁止；停止/退订/拒绝标记
当前唯一下一步 / 负责人 / 下次复核日状态可沿用本专题的 E（地址/入口）、R（角色）、P（路径）分类，但不能只留字母。每个状态都要有简短依据，例如“官网 Supplier 页面公开，E1/P1”“公开职位相关但地区待证，R2”。
| 入口类型 | 来源与用途最低要求 | 典型状态 | 导出规则 |
|---|---|---|---|
| 官网通用/部门邮箱 | 官网 URL、地址显示位置、部门说明 | E1 + R3 | 仅在账户与触达资格通过时 |
| 供应商/RFQ 表单 | 官方 URL、页面目的、提交记录 | P1 | 不是邮箱，按表单流程操作 |
| 公开个人角色页 | URL、当前公司/地区/职责 | R1/R2/R3/R4 | 不自动生成或猜测邮箱 |
| 官方总机 | 官网地点/电话页面、用途 | P3 | 仅用于确认公开流程 |
| 第三方目录线索 | 目录 URL、日期、反查结果 | P4 | 永不直接导出发送 |
去重不是删除，而是识别关系与优先级
同一邮箱、电话、表单 URL 和个人主页应各自去重；但地址相同不一定代表同一联系人，域名相同也不代表同一业务单元。去重时先比较 account_id、国家/地区、来源页和当前状态，再决定合并、关联或保留为冲突记录。历史离职、退信和拒绝记录不能删除，否则它会在下一批数据导入时重新出现。
| 冲突情形 | 处理方式 | 不要做 |
|---|---|---|
| 相同邮箱关联两个账户 | 先核对集团/地区关系，必要时设共享入口 | 随意合并账户历史 |
| 同名不同 URL 的个人资料 | 比对当前公司、地区和职责 | 只因姓名相同就合并 |
| 旧邮箱退信，新官网出现新入口 | 保留旧记录为停止，新建新入口 | 覆盖掉退信历史 |
| 同一表单有多次提交 | 记录每次动作与结果，防止重复 | 因不回复连续刷表单 |
| 联系人换岗 | R4 标记旧岗位，关联新状态 | 删除旧行后失去审计痕迹 |
发送前导出必须经过硬过滤
发送名单不是入口表的复制。导出前必须按账户队列、主体状态、入口来源、触达资格和停止标记过滤。可发送只是“当前符合内部流程的候选”，不代表可以无差别群发；内容、频率和地域规则仍需单独审查。
导出候选 = 账户队列 A/B
AND 主体/产品闸门通过
AND 入口来自官方公开渠道或已获明确业务指引
AND 触达资格为允许/已按流程确认
AND 无退订、拒绝、投诉、硬退信、主体冲突、重复动作
AND 本周期没有超过团队规定的触达频率任何一项无法判断时，记录留在“需确认”，而不是为了凑名单放行。尤其不能因历史贸易数据看起来有价值，就绕过退订、拒绝或来源不明的问题。
虚构示例：一条地址为什么不能被三个人同时跟进
虚构账户 A 有一个官网通用邮箱和一位公开产品经理。通用邮箱属于 P1/E1/R3，产品经理是 R1 但没有公开邮箱。表格应把它们建为两条入口：当前唯一动作可以是由指定业务员通过通用入口确认负责部门，而不是三位业务员分别给通用邮箱、猜测产品经理邮箱和 LinkedIn 同时发消息。
另一个虚构账户 B 在第三方目录里有多个地址，但官网主体仍待核。它们应全部标为 P4/待核，不能导出。表格“看起来更满”并不会提升线索质量，反而会让错误动作更快发生。
每周治理：结果写回，规则才能变好
每周至少检查本周期新增入口、已发送动作、退信/拒绝、重复记录和超期待核项。重点不是统计新邮箱数量，而是检查：哪些官方入口真正导向正确部门？哪些角色总被误判？哪些来源持续产生无效地址？把结果写回原表，才能调整搜索路径、队列规则和停止条件。
| 每周问题 | 应查看的字段 | 可能的改进 |
|---|---|---|
| 为什么重复触达 | account_id、入口 ID、动作日志、负责人 | 强制一账户一主动作 |
| 为什么出现退信 | 来源、域名状态、最后核验日 | 缩短复核周期，停用低质量来源 |
| 为什么无回应 | 入口用途、账户队列、内容/频率日志 | 改先确认部门，减少泛化触达 |
| 为什么主体错配 | 官网归属、地区、名称变体 | 完善实体核验而非再买名单 |
停止与归档规则
收到退订、拒绝或投诉，出现硬退信、明确主体错配、官方页面说明不接收此类资料，或账户降为 D 时，应停止对应入口的外联，并保留原因和日期。归档并非删除：需保留足以防止再次误用的最小审计信息，但不再扩展无关个人资料。只有新的官方公开入口、客户主动提供渠道、或主体/业务证据发生实质变化时，才重新打开记录。
这张记录表是联系方式专题的交付物：它让团队知道每一个入口从哪里来、能做什么、谁负责、何时停。下一专题将把已通过账户和入口接到实际触达流程，而不是把名单本身当作开发的终点。
如果你想把「联系方式获取记录表：证据、状态、去重与发送前治理」这一步继续落成流程，可以看看 客户开发 Agent，先判断它是否适合接住这段重复工作。查看适配方案
引用本文
引用时可保留文章名称、规范地址和页面记录的更新时间。