LinkedIn客户开发CRM字段怎么设计
CRM 的职责是保存可验证事实与下一步，不是堆积画像
LinkedIn 的保存、搜索与提醒可协助发现公开线索，但 CRM 才是团队判断“谁在研究、谁已联系、对方明确说了什么、何时停止”的唯一事实源。字段设计不应追求越多越好；每个字段都应回答一个业务问题，并能说明来源、更新时间和谁负责维护。
尤其要分开记录三类信息：公开事实（官网、当前职位、明确回复）、待验证假设（可能的角色节点）和禁止推断项（预算、采购意向、私人信息）。混在一起会导致团队把猜测当作客户事实。
Account 字段：先让团队知道研究的是哪个实体
| 字段 | 用途 | 正确示例 |
|---|---|---|
| 标准名称 | 统一同一实体的名称 | Rhein Distribution GmbH |
| 官网域名 | 主去重与主体核验 | example.de，含核验日期 |
| LinkedIn 公司页 | 平台研究入口 | 当前公开 URL |
| 实体类型 | 总部/子公司/工厂/销售实体 | 德国销售实体，集团关系已核 |
| 市场与商业角色 | 判断业务边界 | 工业分销商，服务 DACH |
| 场景证据 | 说明为什么匹配 | 官网展示过程设备产品线 |
| 状态与负责人 | 防止重复研究 | 已核验；Owner=A |
员工数、行业、增长等平台字段可以作为初筛参考，但不能替代官网业务事实。客户规模大、应该有需求、高价值不是可审计字段。
Contact 字段：记录当前职业事实，不记录个人画像
| 字段 | 应记录 | 不应记录 |
|---|---|---|
| 当前职位/公司 | 公开显示的职位、实体、核验日期 | “有采购权” |
| LinkedIn URL | 公开资料入口与去重键 | 私人社媒账号 |
| 角色节点 | 产品/技术/寻源/执行等待验证假设 | 预算和内部影响力猜测 |
| 地区/覆盖范围 | 资料明确披露的地点/范围 | “负责整个欧洲”这类推断 |
| 状态 | 主验证、备用、观察、Stop | 热/冷等含糊标签 |
| 来源 | 搜索/官网/公开内容/明确回复 | 未获同意的数据来源 |
企业邮箱或其他联系方式只有在合法、业务必要且来源合规时才处理，并应记录验证/许可状态。不要用 CRM 收集私人邮箱、家庭信息或无关个人特征。
角色路径字段：把“职位”变成待验证任务图
同一公司可以有多人，但不是每个人都应进入触达队列。为每个活跃 Account 保存最小角色图，明确当前主路径和备用条件。
| 节点 | 联系人（如有） | 公开事实 | 待验证问题 | 状态 |
|---|---|---|---|---|
| 产品/需求 | Product Manager | 资料提到产品组合 | 谁评估新增品类？ | 主验证 |
| 寻源/准入 | Sourcing Manager | 当前职位匹配 | 是否接收初筛资料？ | 备用 |
| 技术/质量 | 未找到 | 官网有技术场景 | 谁审核规格/文件？ | 待研究 |
| 订单执行 | Purchasing Manager | 资料提到 PO | 是否只负责执行？ | 观察 |
不要为了表格完整而假定批准人、预算或汇报关系。空白节点是正常信息，提示下一次研究该做什么。
Activity 字段：让每次触达能被复盘
| 字段 | 记录内容 |
|---|---|
| 动作类型 | 研究、邀请、首信、资料发送、跟进、停止 |
| 日期/负责人 | 谁在何时做了什么 |
| 公开依据 | 官网产品线、当前角色或对方公开内容 |
| 唯一问题 | 本次只验证什么 |
| 对方明确回复 | 原意摘要与日期，不添推断 |
| 材料/许可 | 文件版本、对方允许的范围 |
| 下一动作 | 一项动作与到期日，或 Stop |
对方已读、接受连接、点赞、资料浏览都不能自动写成“回复”“有需求”或“商机”。CRM 记录的是证据，而非主观热度。
状态必须有进入与退出条件
待核验 → 已核验 → 角色研究中 → 主路径待联系
→ 已联系 → 已回复/已转介/观察/Stop
→ 仅在明确业务事实与双方许可下进入发现或机会阶段| 状态 | 进入条件 | 退出条件 |
|---|---|---|
| 待核验 | 只有平台线索 | 官网主体/场景核验完成或不匹配 |
| 已核验 | 实体、角色、场景有公开依据 | 建角色图或观察 |
| 已联系 | 有一条基于事实的消息/邀请 | 回复、无回复复核或 Stop |
| 已回复 | 收到有业务意义的明确事实 | 建下一动作或转介 |
| 观察 | 当前无路径/无新事实 | 出现新公开事实后复核 |
| Stop | 拒绝、离职、主体错、无关 | 不再个人触达 |
机会阶段不能仅由 LinkedIn 接受连接或一句“发资料”触发；应有明确场景、双方确认的下一步或实际业务需求。
去重与集团关系规则
Account 的主要去重键通常是官网域名，加上实体名称、国家/地址辅助判断；Contact 可用 LinkedIn URL 和合规的企业联系信息辅助去重。集团、品牌、子公司和工厂不能简单合成一条：需要保留关联关系与各自业务/采购边界。
| 发现情况 | 正确处理 |
|---|---|
| 同域名不同国家实体 | 建关联 Account，核验各自职责 |
| 同名不同域名 | 不合并，先消歧 |
| 同人不同写法 | 以公开资料 URL/当前实体复核 |
| 同公司多人保存 | 指定唯一主负责人和角色状态 |
| 已离职联系人 | Contact Stop，Account 仍可继续研究 |
去重目的不是减少记录数，而是防止错误合并和重复触达。
模拟案例：为什么“采购决策人”不是好字段
以下为虚构例子。业务员把一位 Purchasing Manager 标为“采购决策人”，原因只是职位名。后来对方回复称自己只处理 PO，新增供应商由 Sourcing 与工程审核。若 CRM 原先保存的是职位、当前实体、资料来源和“订单执行待确认”，团队可以平滑更新角色图；若只保存“决策人”，后续成员会继续向他推送不相关资料。
字段的价值在于允许错误被修正，而不是让最初判断看起来很肯定。
每周字段质量检查
| 抽查问题 | 合格标准 |
|---|---|
| Account 是否能回到官网证据 | 有域名、实体边界、场景和日期 |
| Contact 是否当前 | 有公开职位/公司来源与核验日期 |
| 角色是否被误写成权力 | 使用待验证任务语言 |
| 每条活动是否有依据与下一步 | 有唯一问题、负责人、日期/Stop |
| Stop 是否被尊重 | 没有后续重复触达 |
| CRM 与列表是否冲突 | CRM 状态可指导列表使用 |
缺少来源、日期、负责人或下一步的记录不应视为完成。优先补齐关键事实，避免为了格式完整而添加无法验证的数据。
CRM 字段自检清单
□ Account、Contact、角色路径、活动和销售机会被分开记录
□ 公开事实、待验证假设和禁止推断项边界清晰
□ 每条活跃记录都有来源、日期、负责人、状态与下一动作
□ 联系人均关联正确实体；集团/子公司保留边界
□ 角色图保留未知节点，不把职位写成采购权或预算
□ 拒绝、离职、无关和重复路径已进入 Stop/去重规则
□ 未收集不必要私人信息，未把社交动作记作购买意向好的 CRM 让团队在人员交接、平台资料变化和客户回复后仍能看见同一条事实链：为什么研究这个公司、为什么联系这个人、当前知道什么，以及下一步为什么合理。
如果你想把「LinkedIn客户开发CRM字段怎么设计」这一步继续落成流程，可以看看 客户开发 Agent，先判断它是否适合接住这段重复工作。查看适配方案
引用本文
引用时可保留文章名称、规范地址和页面记录的更新时间。