营销软件选型最容易陷入横向功能表：谁有更多渠道、更多报表、更多自动化和AI能力。表格项目越多，真正工作越容易消失。公平比较的单位不应是功能名称，而应是一项从开始到结束、包含异常的真实工作。
这里的“真实工作”指企业确实重复发生的任务，不意味着把真实客户数据交给供应商。可以用虚构或脱敏样本还原结构。比较结论来自测试，不来自行业排行榜，也不保证上线后业绩变化。
先定义采购要解决的问题
写出当前问题、影响对象、发生频率、已有处理和不能接受的风险。例如“重复咨询可能生成两位负责人，客户收到重复联系，且历史来源被覆盖”。不要只写“系统老旧”或“需要增长”，它们无法验收。
再写采购不解决什么：产品适配、客户预算、销售判断和组织责任不会因工具自动消失。范围越清楚，越不容易在演示中不断加需求。
建立同一份比较脚本
脚本包含开始事件、样本、角色、步骤、预期状态、异常、证据和结束条件。每家方案都处理同一条咨询、一次重复、一个已有账户、一次分配、一次失败和一次拒绝。
若某方案采用不同方法，只要能满足任务与边界，可以接受；但不能让供应商跳过困难步骤，用另一个漂亮模块替代。未验证项单独列出。
第一维看任务覆盖
检查从入口、保存、身份、去重、归属、接收、行动到反馈是否完整。功能存在但需要在三个页面手工复制，仍应记录真实负担；某项低频判断由人工完成，也可能比复杂自动规则更可靠。
任务覆盖不是要求所有步骤都在一个产品内完成，而是系统之间的交接清楚、责任明确、失败可恢复。一条咨询的系统流转提供逐步检查方法。
第二维看数据与历史
检查联系人、账户和商机是否分开，首次来源与转化来源是否保留，字段定义和更新方向是否明确，合并是否可撤销，历史能否查询。漂亮看板若建立在覆盖和重复数据上，没有决策价值。
还要查看导入质量、未知值处理和数据导出。旧数据无法判断时应保留未知，不为填满字段进行推测。
第三维看异常和恢复
让接口失败、负责人不可用、字段冲突和重复重试真实出现。比较告警是否可见、谁处理、能否人工补偿、重放是否重复、恢复后历史是否完整。
异常并非边缘功能。系统运行时间越长，权限过期、字段变化和连接失败越可能发生。没有恢复方式的低价方案，长期成本可能更高。
第四维看权限与客户边界
不同角色是否只看工作必要信息，导出和批量发送是否受控，客户拒绝或退订能否在适用流程执行，测试与生产是否隔离。具体要求由企业有权人员按适用制度确认。
不要把权限菜单当作已经配置。要求用不同角色登录测试，并记录仍需人工或其他系统完成的部分。
第五维看实施和日常维护
询问谁设计字段、清洗数据、配置流程、连接接口、培训员工、处理失败、维护版本和支持新需求。把供应商、内部业务、技术和管理员责任分别写清。
系统越灵活，可能越需要治理。若团队没有负责人，再强的配置能力也可能停在演示。采购计划应包含上线后的日常工作，而不只包含交付日期。
第六维算总拥有成本
总成本包括许可、实施、定制、接口、迁移、数据清洗、培训、内部时间、运维、扩容、安全审核和退出。价格要按自己的用户、数据量、渠道和服务范围核对，不引用未经确认的行业数字。
收益则写成可验证假设：减少哪段重复、降低哪类遗漏、让哪个状态可见。上线后用相同工作和口径复测，不能提前把假设写成节省金额。
第七维看退出和可替换性
确认合同结束、产品变化或迁移时能导出哪些对象、字段、关系、附件和日志，格式是否可用，需要多长准备和额外费用。也要知道自定义流程和接口文档归谁维护。
可退出不代表一定更换，而是避免关键业务被锁在无法理解的数据里。采购时考虑退出，能迫使团队先想清主数据和长期责任。
怎样决定买、试还是暂缓
若规则和对象尚未统一，先修流程；若需求清楚但产品能力未验证，做有限范围概念验证；若同一脚本通过、总成本可承受、负责人明确且失败可恢复，再进入采购评估。结论可以是保留现有工具并补规则。
不要用沉没成本推动上线，也不要因单次失败永久否定方案。记录条件、限制与待验证项，让决策可以在事实变化后更新。第25课第一份营销计划可帮助安排资源与里程碑。
一张可用的比较表写什么
每行是一项任务或风险，每列记录方案的通过状态、证据、配置前提、人工步骤、异常处理、负责人和成本。使用“通过、部分通过、未验证、不适用”，不要给未经校准的总分掩盖关键底线。
严重的数据覆盖、拒绝失效或失败不可见不能被大量次要功能抵消。最终结论附上样本范围和未覆盖场景。
怎样把比较结果写成决策备忘录
决策备忘录首先写问题，而不是先写推荐产品。说明当前工作怎样进行、哪些损失或风险已经被观察到、哪些只是待核实、若不改变会怎样。接着列出至少三种选项：继续使用现有方法并优化流程、小范围试行某方案、正式采购和实施。把“不买”作为真实选项，能迫使团队比较软件之外的组织、定义和数据改进，而不是默认预算获批就是答案。
每个选项都按同一维度记录证据：能覆盖哪些关键任务，哪些需要人工或额外开发；数据由谁负责，历史能否追溯；异常怎样发现和恢复；权限与联系人边界能否执行；一次性实施、迁移、培训和持续维护由谁承担；退出时数据、接口和流程如何接续。价格只是总拥有成本的一部分，未来收益也只能写成待验证假设，不能把供应商演示或通用行业说法变成企业自己的效果预测。
推荐结论应明确条件。例如“建议进入有限试行，前提是重复合并、拒绝同步和失败告警三项通过真实样本测试”，比“建议采购，综合得分最高”更能指导行动。若关键证据缺失，就写暂缓以及下一步如何补证，而不是用更多低价值功能抵消。最后记录决策人、异议、复核日期和触发重审的变化，例如产品版本、接口价格、业务流程或适用规则改变。
这份备忘录也应交给未来的实施和运营人员。采购团队离场后，他们需要知道为什么选择、哪些能力尚未证明、哪些人工补偿必须保留。这样，选型结果不会成为一次性文件，而会变成上线验收、阶段复盘和必要退出时共同使用的基线。
决策前再做一次反向检查：如果推荐方案最终没有采购，哪些规则和数据问题仍必须解决；如果采购后没有出现预期改善，团队用什么证据判断是产品限制、实施偏差、采用不足还是原假设错误。提前写清这些问题，可以避免把一切成功归因于工具、把一切失败归因于使用者，也让后续复盘有共同参照。
备忘录以可复核事实为核心，而不是采购立场。
学完这一页要完成什么
选择一项真实工作，完成问题句、同一测试脚本和七维比较表。至少测试一个正常样本、一个重复、一个异常和一个停止条件。写出买、试或暂缓的依据，以及上线后要复测的三项事实。
继续本课：画重复工作、区分软件职责、走查一条咨询、先数字化再自动化和把演示还原成日常工作。
本页来源与禁写边界
- 主要来源：已确认学习单元 `marketing-software.md`；赵岩《B2B数字营销笔记2025》第88—92页；营销自动化系统连接方法；市场与销售SLA；线索来源统一方法。
- 禁写：比较样本是客户案例；功能数量等于适用；报价、周期或节省金额未经核验；购买系统必然提高业绩；某厂商或产品能力未经当前演示与合同确认。