系统架构图上常有很多箭头：官网连营销系统，营销系统连CRM，CRM再连企业协作工具。箭头看起来代表“打通”，但真正的问题是同一条咨询经过每个节点时发生了什么。字段有没有丢，身份有没有错，谁确认接收，失败后谁知道，决定了流程是否可靠。
下面使用一条虚构教学咨询：一位联系人主动提出“想了解多销售团队怎样共同查看跟进记录”。它不是事橙客户，也不证明任何软件能力。我们只用它检查从入口到下一步的完整工作。
第一步保存客户原始表达
入口应保存提交时间、页面或活动、联系人主动表达、必要联系信息、允许用途和原始来源。不要在进入系统前就把“想了解”改成“准备采购”，也不要用页面标签替换客户自己的问题。原始表达是后续判断和复盘的基准。
若信息来自已有沟通或活动约定，同样记录事实入口。课程不要求网站新增表单，也不建议为了完善画像多收无关字段。只保存当前任务需要的信息，并按企业适用规则管理权限和保留。
第二步区分联系人与企业账户
联系人是具体的人，企业账户是组织，商机是围绕某项可能合作形成的业务记录。一个企业可能有多位联系人，一个联系人也可能在不同时点提出不同问题。系统不应因为获得邮箱就假设已经出现完整企业需求。
先核对是否已有联系人、是否属于已知账户、是否存在销售负责人或进行中的商机。个人邮箱、公共邮箱和同名记录可能无法可靠匹配，这时进入人工复核，比强行合并更安全。
第三步处理重复但保留新信息
重复提交不等于无价值，也不等于新线索。若同一联系人此前存在，应把这次新问题、时间和入口追加到历史，同时保持身份主档稳定。若只是技术重试，则避免生成第二个任务；两者需要事件ID、时间和上下文帮助判断。
合并要可追溯、可纠正。不能只保留最新来源覆盖过去，也不能把两个人因公司同名合并。第14课的从联系人到企业账户可以帮助理解对象层级。
第四步保存不同来源维度
外部渠道、承载应用、具体内容和转化入口回答不同问题。联系人可能由合作伙伴首次接触，在官网阅读文章后提交咨询；若系统只保留“官网”，会丢掉首次渠道，若只保留“合作伙伴”，又看不到本次承接页面。
因此优先保存事实与时间，再按决策生成首次、转化或其他归因视图。归因是规则，不是唯一真相。具体字段可参照线索来源统一方法。
第五步按归属规则分配
分配前检查现有客户、已有商机、指定负责人、销售保护和区域或产品规则。规则应由相关团队确认，系统负责执行已配置条件。无法判断时进入待处理队列，不静默分给一个看似合适的人。
分配记录至少包含负责人、时间、依据和上下文链接。群消息可以提醒，但正式归属应保存在可查询位置。否则人员离岗、消息被刷走或重复提醒时，团队无法恢复事实。
第六步让负责人明确接收
系统显示“已分配”只能证明任务被指向某人。负责人需要确认接收，或用结构化原因退回。接收后记录准备、联系渠道、客户约定和下一步；退回则进入对应的补充、培育、排除或重新分配路径。
响应时限不能从其他公司照抄，要结合需求紧迫度、工作日、时区、团队容量和真实测试。已确认的市场与销售SLA提供了接收、退回和反馈的设计思路。
第七步把新问题写回同一关系
联系人后来补充“现有数据在多个表格里”，这应追加到原记录，并区分客户原话、员工判断和待确认事项。销售、市场与实施人员从同一上下文继续，而不是各自在消息里保存半段信息。
若问题涉及未确认产品能力，记录为待核实，不自动生成承诺。软件可以帮助共享事实，不能替产品或实施负责人判断支持范围。
第八步设计异常和人工补偿
至少测试接口超时、字段不合法、重复重试、负责人不可用、通知失败和目标系统权限过期。异常要有状态、时间、原始输入、错误原因、重试次数和人工负责人。重试应避免重复创建，补偿后能回到主流程。
若系统完全看不到失败，团队只能从客户投诉或漏单中倒推。集成验收不仅看成功样本，还要故意制造失败，验证告警和恢复。
第九步执行拒绝与停止条件
客户明确不希望继续接收普通内容时，相关流程应按企业适用规则停止；销售确认已有其他负责人时，不应再次分配；记录被判定不适配或无效时，要保存原因并退出错误路径。停止也是系统功能的一部分。
拒绝不能只写在一条聊天备注里。如果多个工具都能发送消息，团队需要确认状态如何传递、哪里是主责、失败怎样发现。本文不提供法律意见，具体规则由企业有权人员确认。
用什么证据验收整条路径
准备一条脱敏测试记录，从入口走到接收和反馈，核对每个系统看到的ID、时间、字段和值；再重复提交、修改一个字段、让通知失败并模拟退回。截图和日志只保存必要信息，并标明测试版本。
验收结果不写“已经打通”，而写哪些路径成功、哪些需要人工、哪些未测试、失败怎样恢复。第24课的事实与原因分开复盘有助于避免用一次成功解释整个系统。
一条咨询的验收记录怎样写
可以为教学咨询设置一个不含真实个人信息的测试标识，从提交开始逐步记录。第一列写事件时间和执行人，第二列写输入，例如页面、活动标识、客户原话与允许使用的渠道；第三列写预期结果，例如“建立或匹配联系人，同时保留本次咨询事件”；第四列写实际结果和证据位置；第五列写差异、处理人和是否需要重新测试。这样，验收结论不会停留在“看起来可以”。
至少准备三种情境。正常情境验证新联系人第一次咨询能否保存原话、来源、账户关系和负责人；重复情境使用同一测试联系人再次提交不同问题，检查系统是否保留新的事件，而不是简单覆盖或建立无法解释的重复对象；异常情境故意缺少一个字段、让通知失败或让归属条件不匹配，观察流程是否进入可见队列并允许人工补偿。还可以加入拒绝情境，核验停止状态能否跨相关流程执行。
验收时要把“存在记录”和“业务含义正确”分开。页面访问、资料下载或邮件动作可以成为待核实信号，但不能因此自动证明需求、资格或采购意向；系统成功分配任务，也不等于负责人已经接收；CRM中出现商机，更不等于产生收入。每一步只确认它实际能够支持的事实，最后再由人员、状态和业务结果连接成完整证据链。
复测时尽量沿用同一测试标识和步骤，只改变一个条件。例如只改变来源、负责人或拒绝状态，观察哪些记录随之变化。若同时更换页面、字段和流程，就很难知道差异来自哪里。每次复测保存版本、时间和操作者，方便后来者重现结果。
学完这一页要完成什么
用一条虚构或脱敏咨询走完九步，为每步写输入、主责记录、负责人、完成证据和异常。特别检查：首次来源是否保留、重复是否产生新记录、通知是否被误当接收、客户拒绝是否在所有适用流程生效。
继续本课其余页面：先画重复工作、辨认五类软件职责、数字化为什么先于自动化、把演示还原成日常工作和用真实工作比较采购方案。
本页来源与禁写边界
- 主要来源：已确认学习单元 `marketing-software.md`；赵岩《B2B数字营销笔记2025》第68—73、88—92页；营销自动化系统连接方法；市场与销售SLA；线索来源统一方法。
- 禁写：教学咨询来自真实客户；行为自动等于意向；重复必然可以自动合并；系统通知等于销售接收；固定响应时限；一次测试成功证明全部链路可靠。