三位联系人、一家企业和一个项目，怎样记录清楚？

记录三位联系人、一家企业和一个项目时，不是把三个人合并成一条记录，而是分别保留三位联系人的身份、角色、原始问题、来源和互动，再建立一个企业账户保存共同的组织事实，并建立一个采购项目保存共同目标、参与者、阶段与下一步。

三位联系人通过关联进入同一账户和项目；尚未确认的角色、范围和时间继续标为待确认。这样既不会漏掉个人问题，也不会把一家企业和一个项目重复计算成三份客户或三项商机。以下人物、企业和问题均为教学情境，不是客户案例。

先把教学情境的事实原样保存

周一，联系人甲通过官网说明“不同销售团队的线索跟进记录无法统一”；他填写自己是业务负责人。周二，联系人乙通过活动问答询问旧数据导入格式；他填写来自同一家企业，但没有说明与甲的项目关系。周三，联系人丙在采购沟通中询问费用包含哪些范围，并明确提到前两位同事正在参与评估。

团队不能一开始就把三人设为同一项目，也不能把三次咨询都当成独立客户。先保存三条原始互动、三位联系人和各自填写内容，再核对企业及项目关系。丙的说明是重要证据，但仍要由项目协调人或客户方适当联系人确认共同目标。

完整的数量判断见同一家公司多人咨询为什么不等于多个客户。

三位联系人分别保存哪些信息

联系人甲保存身份、业务负责人这一自报角色、官网来源、原始问题和首次互动时间。联系人乙保存活动来源、技术问题和尚未确认的项目关系。联系人丙保存采购沟通来源、费用问题以及他对共同参与关系的说明。

角色字段应标明来源。“本人填写”“客户方确认”“内部推断”具有不同可信度，不能都写成确定事实。联系方式、所属企业、联系授权和最近核对时间也分别保存。后续角色变化不覆盖过去互动发生时的角色。

企业账户和项目的字段模型可继续阅读联系人、企业账户和采购项目怎么区分。

企业账户只保存共同的组织事实

企业账户保存经过核对的规范名称、主体关系、行业或地区等必要组织事实，以及账户协调信息。三位联系人都来自同一企业这一判断，需要保留填写、域名、历史记录或客户确认等依据。

个人问题不应直接变成企业永久属性。甲提出“记录不统一”，最多说明他观察到这个问题；只有经过其他参与者确认，才能把它写入项目共同背景。乙关心导入、丙关心费用，也分别属于他们的当前问题。

账户可以关联多位联系人和多个项目。建立账户不会让联系人消失，也不表示企业已经成交。

采购项目怎样汇总共同目标

采购项目的名称可以写成“跨销售团队线索记录统一评估”，但前提是共同目标得到确认。项目保存所属企业、问题范围、参与联系人、当前阶段、已确认条件、待确认事项、下一步和项目协调责任。

项目摘要要区分事实与假设。例如“甲提出跨团队记录问题”是事实，“客户需要替换CRM”则未被任何人表达，不能补写。乙的导入问题可能是项目条件，也可能是独立咨询；在确认前标为待核对。丙的费用问题说明进入比较，但不证明预算已批准。

一个项目的参与者可以持续增加。新增人员时补关系和角色，不新建第二个相同项目。

一张完整记录表应该长什么样

下面表格扩展自原课程三人示例。来源依据、待确认、下一步和责任人必须与“当前已知”一起展示，避免一列备注混合事实与推断。

责任人栏表示下一步由谁承担，不声称所有公司必须设置同样岗位。复杂团队可区分联系人承接、账户协调和项目推进，小团队可由同一人兼任，但每项待办仍应只有明确承接者。

怎样把事实、推断和待确认分开

表单原文、活动提问、邮件和经授权的会议记录属于发生过的事实；“技术决策者”“项目紧急”“预算充足”若未经确认，只能是推断。项目记录可同时存在“已确认”和“待确认”，不为追求完整把推断升级为事实。

每条关键判断旁边保留来源和更新时间。若客户后来更正范围，新增一条更新并说明旧判断失效，不改写原话。若不同联系人表达冲突，分别保存，再由客户方适当角色或内部约定的核对人确认。

来源事实合并时仍保留首次、本次和关键触点，详见B2B线索来源如何统一。

一次项目沟通前怎样准备上下文

协调人不应只收到三张名片。沟通前摘要包括企业与项目、三位联系人及角色来源、每人原始问题、已经回答的内容、冲突与未知、联系限制、下一步建议和时间。

给业务负责人时可核对共同目标和使用范围；给技术人员时承接导入条件，不重新询问全部背景；给采购时说明哪些范围已确认、哪些需要专业同事补充。任何人都不应看到超出工作需要的个人信息。

上下文的价值是让每次沟通继续推进同一问题，而不是让客户重复教育供应商。

新信息进入后更新哪一层

联系人换岗、联系方式变化或表达新问题，更新联系人及其互动；企业更名、主体关系确认或账户负责人变化，更新账户；项目范围、阶段、参与者和下一步变化，更新项目。一次信息可能影响多层，但不能把个人问题直接写成组织事实。

例如乙确认自己只是外部实施伙伴，就把联系人—企业关系改为外部参与，并保留原填写；项目仍可保留他为技术参与者。若丙询问的是另一项采购，则创建新项目候选，而不是把现有项目范围扩大到失去边界。

更新顺序和字段差异清楚，历史才能解释为什么当前记录变成这样。

重复分配只是这套记录的一个应用场景

当乙的新咨询进入时，系统或执行者先查联系人、账户和项目。确认他参与已有项目后，将新问题加入项目并通知协调人，而不是把他当作全新客户分给另一位销售。若属于同企新项目，则按独立项目规则处理。

市场与销售服务级别约定（SLA）应写清分配、接收、已有账户、已有项目、客户指定联系人、冲突、退回和未响应升级。可参考B2B市场与销售SLA怎么制定。

记录结构先正确，分配规则才有可靠输入。反过来，靠“谁先看到就归谁”无法解决对象关系问题。

怎样处理无法确认或相互冲突的信息

如果三人的企业名称写法不同，先保留原值并核对主体；如果甲说只有一个项目、丙提到另一项采购，分别保留两个陈述，不立即合并或拆分；如果乙的身份无法确认，仍保存互动但不把他写成客户员工。

待确认项要有原因、下一步、责任人和复查时间。长期无法确认时保留未知或关闭候选关系，并说明依据。空值不等于执行失败，伪造确定性才会污染后续统计和客户体验。

批量处理类似记录的方法见怎样把一批联系人整理成企业账户和采购项目。

完成后怎样验收这组记录

从任一联系人进入，应该找到他所属或待确认的企业关系、参与项目、原始问题和下一步；从企业账户进入，应该看到三位联系人和该项目；从项目进入，应该看到企业、参与者、问题、依据、待办和协调责任。

再让没有参与录入的人回答：哪些是客户原话，哪些是内部判断，哪些仍待确认；谁下一次联系谁，为什么不会重复问；如果关系判断错误，怎样回退。只要一项无法回答，就继续修订。

材料来源与结论

本页依据第14课已确认学习单元、赵岩《B2B数字营销笔记2025》第90—92页关于分配、冲突和协作规则的历史讨论，并结合已确认的市场销售SLA与线索来源文章整理。表格人物、企业、问题和责任安排均为教学情境，不是事橙客户记录或CRM能力展示；课件的固定天数、具体系统和归属规则未沿用。

三位联系人、一家企业和一个项目的正确记录，不是三人合一，而是三位联系人分别保留、账户保存共同组织事实、项目保存共同目标，再用来源和确认状态建立关联。这样才既完整，又不会把客户与商机重复计算。