B2B团队常说“线索转成客户”“客户进入商机”，听起来像一条记录不断改名。真正进入系统后，这种表达容易让对象混乱：一个自然人不会变成一家公司，一家公司也不会变成一个采购项目。变化的是业务状态和对象之间的关系，不是事实主体本身。
联系人保存人，企业账户（Account）保存组织，采购项目或商机（Opportunity）保存一次具体合作可能。三类对象各有字段和生命周期，再通过可以追溯的关联连接。一个企业可以有多位联系人和多个项目，一位联系人也可能参与多个项目。
联系人记录的是一位具体的人
联系人是能够被识别并在合法、必要范围内记录的一位自然人。基础字段可以包括姓名、已确认联系方式、所属企业、部门或角色、信息来源、授权状态、提出的问题、互动时间和负责人。
联系人不等于线索阶段。一个人可以先作为活动报名者被识别，后来达到团队的线索条件，也可能因离职、退订或不适配不再进入普通跟进。阶段变化应另有记录，原始身份和互动历史仍需保留。基础区别可链接到访客、联系人、线索和客户有什么区别。
姓名、职位和所属企业都可能变化。更新时记录新值生效时间和来源，重要变化保留历史，而不是让今天的职位覆盖过去沟通发生时的角色。
企业账户记录的是组织主体
企业账户代表需要被统一识别和经营的具体组织。它可以保存规范企业名称、已确认主体、所属关系、行业、地区、规模区间、当前客户关系和账户协调责任等，但只记录有来源且业务必要的事实。
账户不是多个联系人字段的简单汇总。一家企业可能有不同部门、地区或子公司，是否放在一个账户下取决于主体、采购关系、服务方式和内部治理。邮箱域名相同、名称相似或办公地址相近只能帮助发现疑似关系，不能独自决定合并。
ICP描述一类理想企业，账户则是现实中的具体企业。某企业符合ICP只是适配判断，不代表它已经表达需求或成为已成交客户。
采购项目记录的是一次具体合作可能
采购项目描述某家企业围绕一个问题进行的具体评估。可记录业务问题、目标范围、关键角色、已确认条件、当前阶段、下一步、时间、负责人、结果和结果原因。
项目需要事实门槛。浏览文章、下载资料或参加活动只能说明发生了互动，除非进一步核实出具体问题与推进条件，否则不应自动创建商机。同一企业可以同时有多个项目，同一联系人也可参与不同项目；项目结束后，联系人和企业关系仍然存在。
名称可以适配企业流程，关键是写清进入项目的证据、由谁确认、进入后采取什么动作，而不是机械照搬某套CRM状态。
三类对象怎样形成关系
最常见的关系是：多位联系人属于一个企业账户，多位联系人共同参与一个采购项目，该项目又属于这家企业。实际情况还可能包括联系人换岗、一个企业存在多个项目、集团内多个主体共同采购，或外部顾问参与评估。
三类对象需要可稳定识别，关系也应能够单独核对。具体实现可以是关系表，也可以使用现有CRM支持的关联字段；至少让团队追溯对象双方、关系类型、来源、确认状态和更新时间。涉及换岗、关系终止或历史参与时，再记录生效与结束时间。系统能力不足时，也不要用删除旧记录表达关系变化。
最小字段怎样设计才够用
联系人最小字段包括联系人标识、姓名或可识别称谓、已确认联系方式、所属关系、角色、来源、授权状态和最近核对时间。
企业账户最小字段包括账户标识、规范名称、主体或层级说明、已确认行业或地区、关系状态、协调责任、数据来源和最近核对时间。
采购项目最小字段包括项目标识、所属账户、待解决问题、参与者、当前阶段、进入依据、下一步、负责人、更新时间和结果原因。
字段不是越多越好。每个字段都要回答谁使用、从哪里来、多久更新、冲突时谁确认。暂时不影响判断或动作的字段，可以不在第一版采集。
一次新咨询怎样分别更新三类对象
以下为教学情境：已有甲企业账户和“统一线索记录”项目，业务负责人已在项目中。技术同事第一次提交“旧数据怎样导入”。团队先保存这次提交的原始时间、来源和问题，再查询联系人身份；核实他属于甲企业，并由项目协调人确认其问题服务于已有项目。
随后新建或更新技术联系人，建立他与甲企业的关联，把他加入项目参与者，并在项目里新增“导入条件待核对”。账户只补充已确认的共同组织事实，不把技术问题写成企业永久属性；项目增加参与角色和下一步，不重建第二个商机。
若技术同事实际来自实施伙伴，就保留外部参与关系；若他讨论的是另一项目，就新建项目候选。这个完整例子与同一家公司多人咨询为什么不等于多个客户相互补充。
新咨询进入时怎样做四步核对
第一步保留原始互动，包括时间、入口、原文和系统标识。第二步查询是否存在同一联系人或疑似联系人。第三步核对当前所属企业。第四步判断是否与已有项目相关。只有找到足够证据后才建立或更新关系。
若已有联系人换了邮箱，不创建毫无关系的新客户，也不直接覆盖旧邮箱；应保留新触点并核实身份。若新联系人属于已有企业和项目，将其加入参与关系并同步问题；若属于已有企业但讨论新目标，建立独立项目候选并等待确认。批量整理步骤见怎样把联系人整理成企业和项目。
阶段变化为什么不能替代对象关系
MQL、已分配、已接收、SQL、商机、成交、退回和排除是业务状态；联系人、账户和项目是统计对象。某位联系人达到MQL，不表示同企业每位联系人都达到相同状态；某项目成交，也不等于该企业所有项目都成交。
一套可执行的生命周期应为每个阶段写清对象、进入依据、确认人和下一步。可继续阅读B2B线索生命周期有哪些阶段。即使系统把多类对象放在同一模块，报表也要保留对象差异。
身份合并时怎样保留来源和历史
同一个人可能换设备、邮箱或企业，也可能先出现在活动记录，后来由销售补录。合并主档案时，保留每个触点发生时间和原始值；首次来源、本次来源和转化入口不能被最新来源覆盖。
同样，企业更名不等于删除旧名称，项目改范围也不等于改写此前会议。历史值和当前值有不同作用。完整来源治理见B2B线索来源如何统一。
异常关系怎样处理
同名不同企业、公共邮箱、同号不同人、旧编号复用、集团域名和员工换岗都可能造成误判。系统可给出候选，确认者需要查看企业、部门、已确认联系方式、历史负责人、互动时间和客户说明等证据。
证据不足时分别保留，标记疑似关系、冲突类型、待补证据和下一位核对人。强行合并会串错来源、授权和销售记录；强行拆分又会造成重复联系。未知状态应能被查询和复查。
责任与权限怎样安排
复杂团队可以按需要区分联系人维护、账户协调和项目推进责任，小团队可以由同一人承担。重点不是岗位数量，而是出现新咨询、换岗、冲突和项目变化时，知道谁确认、谁更新、谁对外协调。
个人信息只在合法、必要范围内保存和使用，访问权限、保留期限、删除和纠错遵循企业制度。本文说明记录结构，不构成法律意见，也不假设任何具体CRM具备某项功能。
完成后怎样验收模型
选择一条新咨询，从互动追到联系人、账户和项目，再反向检查。要求回答：原始问题在哪里，身份和企业关系依据是什么，项目是否真实存在，首次与本次来源是否仍在，未知如何标记，下一步由谁承担。
再从企业查看全部联系人与项目，从项目查看参与者和历史互动。三条路径能够对应，且关系变化不需要删除历史，模型才真正可用。
材料来源与结论
本页依据第14课已确认学习单元、赵岩《B2B数字营销笔记2025》第71页关于联系人与企业主体的讨论，以及已确认的客户画像和线索来源文章整理。没有把课件中的严格状态顺序、账户锁定方式或具体系统对接写成通用数据模型。
联系人是人，企业账户是组织，采购项目是事情。分别建立稳定对象，用现有系统可承载的关联保存来源和确认状态，遇到变化保留历史，才能让多人咨询和后续统计可靠。