软件演示往往从一套整理好的数据开始：联系人完整、字段一致、流程顺利、看板漂亮。真实工作却有重复邮箱、历史负责人、缺失字段、接口超时和客户临时改变计划。只看顺利路径，团队容易把“产品能展示”误认为“我们的流程已经可用”。
更有效的方法是把演示改造成任务验收。选择一项已经画清的日常工作，准备虚构或脱敏样本，让每家供应商完成同一组步骤。问题要从客户动作开始，而不是从菜单名称开始。
演示前先写测试目标
写清本次要判断什么，例如“新咨询能否在不覆盖历史来源的情况下更新已有联系人，并由当前负责人确认接收”。同时写不测试什么，避免会议临时扩展到全部功能。目标决定样本、角色和通过条件。
参与者至少包括实际使用者、流程负责人和能判断数据或集成的人。采购或管理者可以观察成本与风险，但不能只凭界面替日常使用者作结论。
准备一条安全的教学记录
样本使用虚构姓名、虚构企业和无实际用途的联系方式，字段结构接近工作但不包含客户秘密。准备首次咨询、同一联系人再次咨询、同企业第二位联系人和一个无法可靠匹配的记录。
为每条样本写预期结果：更新、建立关联或进入人工复核。若供应商需要上传真实数据库才能展示，应先由企业有权人员评估，不因“演示方便”扩大数据使用。
测第一次进入和来源保存
让咨询从实际入口或等效测试入口进入，核对时间、原始问题、允许用途、渠道、承载页面、内容和转化动作。查看哪些字段自动获得，哪些来自配置，哪些不可用。
然后检查首次来源是否独立保存，后续触点是否追加。若一个字段每次被覆盖，看板将无法回答不同来源问题。线索来源统一方法可作为字段讨论依据。
测重复与账户关系
让同一联系人再次出现，观察系统是更新历史、重复新建还是提示人工判断；再让同企业另一联系人进入，检查是否能建立账户关系而不把两个人合并。询问匹配条件、冲突优先级和纠错方式。
“支持去重”不是答案。要知道依赖邮箱、电话、域名还是自定义ID，公共邮箱怎样处理，合并后是否保留来源和操作记录。
测分配、接收和退回
设置已有负责人、无人负责和负责人不可用三种情况。检查归属依据、任务是否真正进入CRM、通知是否携带上下文、负责人怎样确认接收、拒绝或退回需要哪些原因。
若销售只收到群消息却无法回写状态，流程仍未闭环。退回要对应补充、培育、排除或重新分配，不是把记录扔回一个无人负责的池子。
故意制造一次失败
让字段值不合法、暂停目标接口或模拟通知不可用，查看错误是否可见，谁收到告警，重试会不会产生重复，人工补偿后是否回到原任务。供应商若只能口头说明，也要标记为待验证。
成功演示只能证明一个样本走通；失败演示更能说明运营能力。记录日志保留多久、能否导出、是否区分测试与生产，以及需要什么权限。
测拒绝、权限和停止
模拟联系人明确拒绝普通内容，检查适用流程是否停止；不同角色登录，检查能否只看到工作必要字段；更正一条记录，查看变更是否可追溯。具体处理按企业适用规则确认，本课不提供法律判断。
不能因为系统有权限菜单就宣布安全，也不能因为一个渠道停止就假设其他渠道同步。要求演示实际配置和失败状态。
测导出、迁移和退出方案
查看关键对象、字段、历史和日志能否按需要导出，格式是否可理解，删除产品账号或结束合作后怎样取得数据。迁移不仅是第一次导入，也包括未来升级、合并和更换工具。
把“可导出”拆成对象范围、频率、权限、额外费用和可重建关系。若数据只能导出成失去关联的表格，退出成本会高于预期。
记录演示背后的实施工作
每个通过项注明前提：是否需要额外模块、接口开发、字段清洗、顾问配置、培训或长期管理员。演示人员现场手工修正的数据，不应被记录为系统自动能力。
同时记录未回答问题和验证方式。不要在会后凭印象补“应该支持”。产品版本和能力会变化，采购前应取得可核对说明。
怎样形成演示结论
按任务给出“通过、部分通过、未验证、不适用”，附证据和限制。部分通过可能足够，例如低频冲突允许人工处理；高风险失败不可见，则即使功能丰富也需要谨慎。
结论还要包含日常负责人、维护工作和总成本。第1页的重复工作地图提供需求基线，第24课月度复盘可用于上线后继续校准。
把演示脚本分成三轮
第一轮只跑正常路径，让一位日常执行者从真实入口开始操作，而不是由售前人员从已准备好的后台记录开始。观察他是否知道下一步、需要复制哪些信息、在哪里确认完成，以及哪些动作必须离开系统。正常路径的目的，是确认产品能覆盖工作最基本的起点、交接和终点，并暴露演示者默认省略的人工步骤。
第二轮专门测试边界。重复联系人怎样匹配，企业名称不一致怎样处理，字段缺失是否阻断，负责人休假时任务去哪里，来源冲突是否保留历史，通知失败是否可见，客户拒绝后哪些流程停止。边界测试不是刁难产品，而是验证日常一定会出现的例外有没有清晰责任。若答案是“可以定制”，继续问由谁配置、属于哪个版本、需要什么数据、多久维护一次以及失败后如何恢复，并把尚未现场证明的部分记为待核实。
第三轮测试运营与退出。让管理员修改一条规则、增加一个字段、查看操作历史、导出样本，并说明版本升级、接口变化、权限交接和合同结束时的数据安排。很多演示把重点放在首次搭建，却忽略上线后的内容更新、人员变动和故障处理。执行者觉得顺手、管理员能够维护、负责人看得到风险，三者同时成立，才算对日常工作有较完整的验证。
三轮都用同一张记录表评分，但不要急于合成一个总分。任务覆盖、数据可信、异常恢复、客户边界、维护成本和退出能力分别给出证据，关键条件不满足时单独标红。邀请真正做这项工作的人参加，并允许他现场提出“我们每天并不是这样做”的异议。演示脚本的价值，就在于把漂亮功能还原为团队将要承担的具体工作。
演示结束后安排短复盘，让执行者分别写下“今天被证明的能力”“依赖配置或服务的能力”“没有看到证据的能力”和“与本公司流程不适用的能力”。四类结论不可混写。供应商会后补充材料时，也应回到原测试项，标明版本、条件和责任，而不是用更多功能介绍替代未完成的验证。
若多人参与评审，先让每个人独立记录，再集中讨论。独立记录可以减少职位、销售表达或现场氛围对判断的影响。出现分歧时回放同一个步骤，确认分歧来自事实、业务优先级还是使用习惯；事实不清就补测，优先级不同交由有权负责人决定，使用习惯则评估培训和迁移成本。不要把所有分歧都归结为“员工抗拒变化”。
学完这一页要完成什么
写一份九步演示脚本，至少包含首次进入、重复、账户、已有负责人、接收、退回、失败、拒绝和导出。为每步写预期结果、证据、配置前提和未通过后的处理，不用界面美观代替工作验收。
继续本课：先画工作、理解软件职责、走查咨询流转、先数字化再自动化和采购前同场比较。
本页来源与禁写边界
- 主要来源：已确认学习单元 `marketing-software.md`；赵岩《B2B数字营销笔记2025》第88—92页；营销自动化系统连接方法；市场与销售SLA；线索来源统一方法。
- 禁写：演示样本是真实客户；一次演示证明生产稳定；厂商宣称等于当前能力；所有冲突都应自动处理；固定节省时间、实施周期或提升结果。