在一个示例商店里，营销操作员每周五下午都要核对新客户是否进入邮件平台。拟议的同步会用报告和异常清单代替核对。操作员想知道清单是否可信，以及记录缺失时该怎么办。
批准购买的店主则问另一个问题：客户数据会怎样处理，谁能启用营销受众，团队以后要承担什么工作？
两个问题都合理。一个产品必须同时回答。
一场关于价值主张的工作坊明确区分使用者与付款者：两者不同时，各自需要以自己的尺度看到价值。来源讨论的是另一种产品场景；对业务集成，这个区别能防止常见销售错误：证明功能对操作员有用，却没有支持购买者的决定。
向执行工作的人展示任务
操作员需要的证据是真实工作流。选一条客户记录，展示它从源系统到目标系统的路径。哪个字段负责身份？哪个属性承载同意？目标系统拒绝某个值时会发生什么？操作员能找到失败记录并理解修法吗？
支持的应用列表回答不了这些问题。API 操作数量也不行。操作员需要证据，证明特定的每周例行工作变短或更可靠。
对新集成，最好的证明可能是范围有限的预览。展示十条代表性记录、拟议映射及目标系统中的结果状态，至少包含一项异常。十条普通记录组成的完美样本，可能掩盖最耗费操作员时间的部分。
Tajo 的Brevo 集成指南介绍实际连接。购买者和使用者的问题在设置之上：谁的工作得到改善，在它成为日常流程前，谁必须信任这项改变？
两类证据可以在同一次试点中收集，却不能装作同一个指标。请操作员用少量代表性记录完成任务，同时记录授予了哪些权限、哪些数据跨越边界、谁能撤回错误映射。任务顺畅但访问不受控，不是成功试点；治理严密但操作员用不了，也不是。
向承担风险的人展示风险
购买者可能从不看字段映射，但仍承担映射错误的成本。如果集成把客户放进错误受众，影响可能在设置结束后继续存在。因此，购买者需要一份简短说明，讲清访问、批准、审计和恢复的责任。
这不需要厚厚的治理手册。需要与拟议任务直接相关的答案：哪些数据离开商店，哪个系统接收，谁能改映射，什么证据说明同步正确运行？若启用需要人批准，就清楚展示那一点。
“操作员喜欢，采购就会跟进”是合理的质疑，有时也会发生。但操作员的成功演示无法证明数据边界或持续成本。同样，购买者批准也无法让糟糕的日常工作流变得可用。把任一方当成充分条件，缺的一半就会在购买后出现。
多业务工具集成指南从工作流、触发条件和权威来源入手。购买者的证据也应围绕这些选择组织。目标系统与数据负责人是商业事实，不是隐藏的实现细节。
购买决定还有时间差。日常使用者立即感受到设置阻力；购买者可能几周后才看到错误受众的后果。演示往往偏向很快显现的东西。因此试点应有延后检查：回访目标记录，确认承诺的状态是否仍在。这会把功能演示变成实际工作流的证据。
操作员检查记录是否达到正确状态，购买者检查成本、权限和风险。同一试点记录连接两类证据。
别忘了记录所代表的人
还有第三种视角：数据被移动的客户本人。他们通常不在采购会议里，但许可和预期仍限制操作员与购买者能做什么。
示例中，一位拒绝营销的客户，不能仅因所有字段到达目标系统就被算作“同步成功”。正确结果包含许可状态。这就是购买者的风险证据与操作员的字段证据在同一记录上相交的原因。
有用的试点报告可以有三行：操作员的任务时间或异常数量、购买者的成本与控制证据、最终客户受到保护的状态。不要用编造的数字填充。试点前先商定检查，再收集数据。
这种方法需要更精确的调研。你必须与操作、批准和受工作影响的人交谈。回报是产品按改变的工作接受评判，而不是按能背出多少功能。
购买也许只需一个签名，证据却有不止一类读者。
常见问题
为什么区分使用者和购买者？
使用集成的人需要任务变简单或更可靠；付款或批准的人需要证据，证明收益超过成本、风险和采用所需的工作。
操作员需要什么证据？
展示具体数据任务可以完成、检查和修复，且不引入不合理的新工作流。
购买者需要什么证据？
展示成本、责任、访问边界和可衡量的业务结果。不要用功能演示替代购买者的风险判断。