许多团队开始讨论营销软件时，会先列出CRM、营销自动化、CDP、分析平台和各种连接能力。名字越多，会议越像在进步，但没有人能回答：今天一条新咨询到达后，究竟在哪保存，谁检查重复，谁确认接收，结果写回哪里？采购前最有价值的动作，是选一项反复发生的工作，把它原样画清楚。
课程采用一个教学场景：新咨询到达后，小陈复制信息到共享表，搜索是否已有销售负责，再把摘要发进群。第二天他要追问有没有人接，第三天发现同一联系人又产生了一条记录。这个场景不是客户案例，它只是让抽象的“营销数字化”落到可以观察的动作。
为什么不能从软件清单开始
功能清单回答产品可以展示什么，不回答你的团队现在卡在哪里。两个系统都写着“线索管理”，一个可能侧重营销培育，另一个可能围绕销售商机；同一个“自动分配”，也可能只按地区轮转，未必能处理已有客户、指定负责人和冲突账户。
若团队只说“我们需要全链路”，供应商只能用自己的产品结构替你定义问题。结果往往是买回许多模块，再把原来不清楚的字段、状态和责任照搬进去。先画工作，可以把演示变成验证，而不是让漂亮界面替业务做决定。
选择什么工作最适合练习
第一项工作不必最复杂，应该高频、边界较清楚、失败能被看见。新咨询分配、活动报名确认、销售承诺资料发送、退回线索重新处理，都适合作为起点。不要第一天就尝试重建整个客户旅程，因为参与角色、例外和历史数据会迅速失控。
选择时写明：它服务谁，什么事件开始，什么状态算结束，目前最明显的重复或风险是什么。例如“客户主动提出产品问题后，信息能够进入唯一记录，由负责人确认接收并保存下一步”，比“提升线索效率”更适合验收。
用九个节点还原现状
从入口开始：咨询来自哪里，是否有明确请求和允许用途；接着看记录保存在哪里，是否有稳定时间和原始内容；身份怎样识别，是联系人还是企业账户；重复怎样判断；已有负责人如何保护；新任务分给谁；接收用什么状态证明；行动与客户约定怎样保存；未送达、无人接收或系统失败由谁处理。
每个节点写“现在实际怎样做”，不要先写理想方案。手工复制并不天然落后，只要量小、责任清楚、记录可靠，它可能足够；自动接口也不天然先进，如果失败不可见，反而会制造更隐蔽的遗漏。
把动作、状态和消息分开
“群里通知了”是一条消息，不等于负责人接收；“系统已分配”是一个状态，也不等于已经联系；“发出邮件”是动作，不等于客户收到或理解。流程图必须把这三类事实分开，否则一个绿色提示会被不断越级解释成业务完成。
可以为每一步规定完成证据：负责人主动确认、CRM状态变更、下一步日期被保存、失败队列出现可处理记录。证据必须来自真实配置；若现有工具只能发通知，就如实写“通知已发，接收未知”。
先识别规则问题还是工具问题
同一联系人重复创建，可能是系统没有匹配能力，也可能是团队没有统一使用邮箱、电话或账户ID；线索无人处理，可能缺提醒，也可能根本没有接收责任；来源被覆盖，可能是接口错误，也可能是首次来源和转化来源被塞进同一字段。
先问“没有软件时我们能否把规则说清”。如果答案是否定，采购不会自动产生共同定义。第25课的第一份营销计划可以帮助把任务、负责人和资源写入计划；规则清楚后，再判断哪些重复动作值得工具承担。
为每一步写五项信息
建议至少记录输入、动作、输出、负责人和异常。以去重为例：输入是新咨询的已授权标识与现有记录；动作是按经确认字段匹配并允许人工复核；输出是更新旧联系人或进入待确认队列；负责人是数据或运营角色；异常包括公共邮箱、同名联系人和字段缺失。
这五项会自然形成软件需求。需求不是“支持智能去重”，而是“重复提交时保留新问题与时间，不新建第二个联系人；无法可靠匹配时进入人工队列；合并可追溯并可纠正”。这种描述才能在演示中被检验。
怎样记录失败而不是只画顺利路径
正常路径通常人人会讲，真正拉开差异的是失败：表单已提交但接口超时，通知发出但负责人离岗，CRM字段枚举变化导致写入失败，重试后出现重复记录，客户拒绝继续接收但另一工具仍发送内容。
为每个失败写清发现方式、责任人、补救、是否会重复以及如何回到主流程。没有失败处理的自动化只是把手工问题藏进接口。已确认的营销自动化系统连接方法进一步解释了幂等、告警与人工补偿。
如何估算手工成本但不编造收益
记录一轮任务实际需要哪些步骤、由哪些角色完成、哪些环节反复返工，并在本团队真实窗口中采样。不要抄别人的“每天节省几小时”，也不要把演示速度当生产速度。新工具还会增加配置、培训、数据迁移、权限和维护成本。
比较时可写成范围：当前哪些动作重复、错误会造成什么业务风险、预计由软件减少哪一段手工、哪些判断仍需人完成。只有上线后用相同口径复测，才能知道成本是否真的下降。
一份可交给供应商的工作卡
工作卡包含：任务名称、开始事件、结束状态、涉及对象、九个节点、关键字段、主责记录、角色权限、三个常见异常、现有样本和验收方式。样本使用虚构或脱敏内容，不把真实客户资料直接带入公开演示。
把同一张工作卡交给不同供应商，要求逐步演示。这样比较的是同一问题，而不是甲展示报表、乙展示群消息、丙展示AI功能。功能没有进入工作卡，就先记作扩展项，不让它转移当前判断。
怎样从现状图得到需求优先级
现状图完成后，不要立刻把每个不顺手之处都写成“系统必须具备”。先逐项判断四件事：问题多久发生一次，发生后影响谁，错误能否被及时发现，以及恢复需要谁投入多少工作。高频但容易人工修正的小麻烦，与低频却会造成错误触达、来源覆盖或客户状态丢失的问题，优先级不能只按发生次数排序。
可以把需求分成三层。第一层是上线前必须成立的业务底座，例如唯一对象规则、负责人、拒绝状态、权限和失败告警；这些缺失时，流程可能伤害数据或客户关系。第二层是显著减少重复劳动、但暂时可由人工补偿的效率需求。第三层是便于使用的体验改善，例如界面排序、批量操作和个性化视图。分层的目的不是压低需求，而是让有限的测试时间先验证真正决定流程能否运行的条件。
每条需求还要标出证据状态。“已观察”写明真实发生过的步骤与问题；“待核实”写明目前只是同事反馈或推测；“未来设想”说明尚无实际流程。供应商可以帮助验证未来能力，但不能把产品演示中的顺畅路径当作企业已经存在的需求。这样整理后，团队得到的不只是采购清单，而是一张能够持续修订的工作改进路线图。
学完这一页要完成什么
选择一项重复工作，用九个节点画出现状；每个节点补输入、动作、输出、负责人和异常。圈出最耗时、最容易错、最难追溯的两处，分别判断是规则、数据、容量还是工具问题。最后写一句可验收需求，不出现“赋能”“打通”“智能化”等无法检验的词。
继续本课其余页面：软件名字分别指什么、让一条咨询走过系统、为什么先数字化再自动化、怎样用日常工作测试演示和采购前怎样做同场比较。
本页来源与禁写边界
- 主要来源：已确认学习单元 `marketing-software.md`；赵岩《B2B数字营销笔记2025》第88—92页；B2B营销自动化系统连接方法；B2B市场与销售SLA。
- 禁写：教学场景是事橙客户案例；固定处理时长或节省金额；软件自动解决规则和责任问题；群通知等于销售接收；采购系统必然提高业绩。