第 9 章｜从试点到真实采用
澄川试点开始三天后，项目群里发出一张截图：四名试点销售全部登录，激活率 100%。业务经理问，是否可以把入口开放给整个销售部。
运行记录给出了另一幅图景。一名销售只打开过示例任务；一名销售生成预览后回到原来的手工流程；还有一名连续用了三次，却在客户关联失败后不再尝试。四个人都登录过，却并非每个人都形成了新的工作方式。
第 8 章证明系统具备进入辅助型试点的控制条件。试点要观察的是另一种事实：用户面对自己的客户、自己的时间压力和自己的责任时，会不会使用、修改、拒绝或绕开系统；这些行为带来的净收益，能否覆盖审阅、支持、维护和风险成本。
本章继续使用“澄川工业客户跟进助手”教学案例。人物、周期、任务数、指标和试点结果都是教学材料，不代表真实企业结果、统计结论或行业推荐规模。
试点是一段受控的真实运行
演示让参与者看懂方案，离线评估让团队复查预期行为，试点则把方案放进有限的真实任务。用户不按演示脚本行动，数据也不会为了测试保持整洁，这正是试点要学习的内容。
受控范围必须先写清。澄川只允许四名授权销售处理已经存在的商机，AI 准备客户需求、风险备注、下一步动作和下一步负责人。销售确认后，确定性工具才可写入这四个正式 CRM 字段。
价格、预计成交日期、商机阶段和外部消息继续禁止。来源冲突、记录版本变化和写入状态未知都会停止任务。项目组保留撤销写入身份和切换回人工流程的能力。
项目组为试点选择了四名销售和十个工作日。四人分别具有不同年资和客户类型，任务频率足以观察重复使用，支持人员也能在出现问题时及时响应。这个选择来自案例条件，不是“四个人、两周”天然正确。
真实项目要从决策需求倒推范围。若任务低频，十个工作日可能没有足够材料；若动作高风险，一次真实写入也可能过多；若要估计细小效果，样本和设计需要统计专业人员参与。课程数字只能帮助读者看懂方法。
GOV.UK 关于 beta 阶段的指南建议先邀请有限用户使用服务，以便收集反馈、改进并准备支持能力。它提供了可借鉴的受控扩展思路，但澄川仍需根据企业数据、权限和 AI 风险作自己的决定。
先选择试点模式，再谈自动化程度
风险较高、权限未开放时，可以让系统与人工流程并行运行，不改变业务状态。这是影子模式，主要收集质量、失败与轨迹证据。
系统准备建议、人确认后才影响业务，属于辅助型模式。澄川选择这一层，因为字段写入可逆、销售能够判断，并且第 8 章已经验证了权限、幂等和停止机制。
受控真实运行会允许系统在白名单范围内直接产生业务动作，仍有监控和退出条件。它需要更强的稳定性证据。澄川没有因为“人工确认率看起来不错”就提前获得这一权限。
影子运行：AI 结果不改变业务
↓ 质量与控制证据充分
辅助型：人确认后由确定性系统执行
↓ 真实采用、稳定性与风险证据充分
受控真实运行：白名单动作可直接执行自主性变化是新的风险决定，不是使用人数变多后的自然奖励。每次从一层走向下一层，都要重新检查动作、影响、回退和负责人。
把“使用”定义成一次业务任务
试点数据最容易被入口指标误导。账号开通、页面访问和模型调用都可能来自培训或测试，不能算用户完成了工作。
澄川把一次有效任务定义为：符合范围的客户会议结束后，销售用自己的身份启动流程，核对带来源的预览，作出接受、修改、拒绝或转人工决定，并让任务到达一个可解释的终点。
提交并不是唯一的成功结果。资料冲突时转给内容负责人，也可能是正确完成；销售有理由拒绝错误建议，也说明人审有效。这里把放弃定义为：任务停在中间，用户转回原流程，却没有留下原因和状态。
项目组按照同一组 meeting_id 和 opportunity_id 连接试点入口、工作流轨迹、CRM 凭据和人工记录。内部测试账号与演示调用被排除，避免把项目组自己刷出的流量算成采用。
GOV.UK 关于完成率的说明把完成率的分母定义为真实开始的交易，并要求排除内部测试用户。澄川借用了“起点、终点和真实用户必须可识别”的测量原则，没有把政府服务的强制指标直接搬成企业课程标准。
24 个任务怎样走过采用漏斗
十个工作日内，四名销售共有 24 个符合范围的会后任务。21 个任务启动了 AI 流程；其中 3 个因为客户与商机关联失败，在预览前回到人工流程。18 个看到了预览，14 个经过确认写入 CRM。
若报告只写“14 次成功写入”，读者看不到前面 10 个任务去了哪里。采用漏斗必须保留符合范围、开始、得到可用预览、作出决定和再次使用各层分母。
24 个符合范围的任务
→ 21 个启动流程
→ 18 个到达预览
→ 14 个确认并提交
→ 2 名用户在后半程仍能独立重复使用用户层面的差异比总量更有解释力。第一名销售六次任务全部提交，最后两次不需要项目组帮助。第二名提交五次，拒绝一次错误负责人建议，也能独立处理。
第三名启动五次，只完成三次。一次客户关联失败后，她开始担心会议会对应到错误商机，后面的任务先用旧流程。第四名启动四次但没有提交；他的任务多为续约与渠道会议，批准资料没有覆盖这些语境，建议显得笼统。
项目组因此把“稳定采用”暂定为：目标用户在多次符合范围的任务中重复使用，并在后期不依赖项目组完成。这个定义适合当前教学决定，不是行业通用留存指标。
四人登录率为 100%，稳定采用者却只有两人。入口数据没有错，只是回答了一个较浅的问题。扩大决定需要更接近工作行为的分母。
局部提速如何变成净负担
第 6 章记录的 44 分钟任务只是一条样本。试点前，项目组继续收集可比任务，形成一组扩展基线；任务差异仍然很大，因此报告同时保留分布、任务类型和个体差异，没有把一个均值当作所有销售的时间承诺。
在 14 个完成提交的试点任务里，端到端时间的中位数低于同类人工任务。生成本身只占很小一段，销售仍要检查来源、修改字段并确认。五次提交出现了会改变业务含义的人工修改，不能把这些时间写成“模型已节省”。
更大的成本出现在任务之外。项目组要处理客户关联、解释阻塞、更新资料、核对日志并陪跑第一次使用。十天内的支持与修复时间超过了已完成任务节省的人工时间，因此本轮净人工收益仍为负。
这不等于方案一定没价值。试点阶段有一次性学习和修复成本，后续单位成本可能下降，也可能降不下来。团队当前能报告的只有：窄场景里看到了提速信号，但这一轮算上支持和修复成本，净人工收益还是负的。
当前净价值判断
= 完成真实任务节省的有效工作 + 可归因的业务改善
− 审阅、纠错、陪跑、支持、维护与运行成本
− 已发生风险损失与需要计入的风险暴露模型调用费只是运行成本里很小的一块。销售审阅要时间，内容负责人维护资料要时间，工程师处理适配器、治理人员复查事件也要时间。这些时间如果不记，AI 项目看起来会比实际便宜很多。
质量、风险和业务结果要分开报告
14 次正式字段写入都拥有销售审批和 CRM 凭据，没有出现禁止字段、重复任务或外部消息。两次记录版本变化被系统阻塞，一次资料冲突转给内容负责人。它们说明当前控制发挥了作用，不能据此声称风险为零。
质量层面，五次实质修改集中在负责人和风险备注。项目组把修改片段加入评估集，并区分模型错误、资料缺口与业务人员偏好。若只报“人工修改率”，这三类原因会被混在一起。
业务层面，项目没有观察到足以支持销售转化、客户满意度或收入变化的证据。周期短、任务少，成交还受到客户预算、关系和产品等多种因素影响。把 CRM 填写提速写成“提升成交”，超出了证据能支持的范围。
GOV.UK 关于服务成功度量的指南建议把性能数据与可用性研究、用户反馈、支持和成本等多种来源结合。澄川也把日志、任务观察、访谈、CRM 状态和支持记录放在一起，而不是让单一看板代表全部事实。
稳定使用者、放弃者和绕开者说了什么
项目组没有只访谈两名稳定采用者。第一名销售认为来源并排展示减少了反复找资料，且入口贴近 CRM；她仍希望系统记住自己对负责人字段的常用修订。
第三名销售解释了放弃原因。问题不是不会操作，而是一次关联失败后，她无法确认预览针对哪个商机。即使系统没有写错，信任已经下降。修复方向应是让关联关系更清楚、失败后更容易恢复，而不是再办一场培训。
第四名销售属于绕开者。他的续约会议需要查看合同和历史承诺，当前批准资料只覆盖产品能力。系统给出的建议没有错，却缺少完成任务所需的上下文。他选择旧流程，是合理适配，不是抵制新技术。
稳定使用者帮助团队找到保留项，放弃者暴露信任断点，绕开者说明适用范围写得过宽。若试点只邀请热情用户回答满意度问卷，最后一类证据通常不会出现。
采用研究还要关注未进入系统的人。符合范围的三个任务没有启动，原因分别是时间压力、忘记入口和认为任务不适合。项目组把这些原因记入分母，不把“用户没有反馈”解释成“没有问题”。
第一次失败会决定用户还来不来
试点第五天，一次 CRM 记录版本变化让提交被拒绝。系统提示“数据已更新，请重新生成预览”，但没有告诉销售原来的修改是否会保留。她担心十分钟审阅白费，直接回到手工录入。
技术上，版本检查成功阻止了覆盖新数据；采用上，这次体验仍然失败。项目组当天补上草稿保留和差异重新合并说明，并让支持人员陪同完成下一次任务。
这个例子说明，安全停止只是第一步。用户还要知道发生了什么、哪些工作被保存、接下来能做什么、谁会处理。错误信息、支持响应和恢复路径都会影响信任。
试点期间的修复仍要经过回归与范围审查。用户着急并不构成绕过权限或直接改正式环境的理由。高风险边界保持稳定，交互和支持可以快速调整。
试点之后应该怎样继续
团队需要综合使用、质量、业务、风险、负担和成本，决定试点之后怎样继续。澄川没有选择扩大范围。两名销售显示出重复使用和局部提速，字段控制也按预期工作；另外两名的放弃与绕开说明场景定义仍然过宽，本轮净人工收益也未覆盖支持与修复。
项目组作出“缩小并迭代”决定。下一轮只保留已有商机、客户关联明确、资料覆盖充分的标准跟进会议。续约、渠道、新线索和需要合同历史的会议退出范围。
改进项只有三类：把入口放进 CRM 当前商机页，明确展示会议与商机关联；保留版本冲突前的人工修订；补全风险备注和内部负责人的评估样本。系统不会增加自动提交权限。
下一轮邀请两名稳定用户和一名曾经放弃的用户继续，以检查修复是否减少支持依赖。内容负责人、技术负责人和业务负责人分别承担资料、系统和采用决定。到期后重新判断扩大、缩小、修改还是停止，而不是默认续期。
这个决定没有否定整个项目，也没有把微弱信号包装成成功。已经得到验证的价值就限定在更窄场景里，尚未得到验证的部分留到下一轮迭代。第 10 章将据此判断：这条窄流程应该作为一次性交付、做成团队内部产品，还是只保留少数组件和资产。
几种容易得出错误结论的做法
光看登录和调用次数不行——培训时的点击、测试调用、无效尝试都会被算成“使用”。任务得有清楚的起点、终点和业务身份才算数。
只分析完成了的任务，会产生幸存者偏差。澄川如果只看那 14 次提交，就会漏掉关联失败、放弃和绕开的十个任务，时间改善也会被夸大。
只访谈积极用户也有问题。你会把范围问题误写成个别人态度不好。稳定用的、放弃的、绕开的，还有根本没开始用的，都得覆盖到。
只算生成速度漏掉了大头。准备、审阅、返工、支持、知识维护和事件处理都要算时间，端到端耗时和组织负担要分开记。
别拿短试点证明收入增长，那是把相关性写成因果。小范围试点适合发现机制、失败和采用信号；要得出因果结论，得用跟问题匹配的实验或准实验设计，拉统计和领域人员一起看。
零事故不等于零风险。样本有限、用户和任务都受控，报告里应该写“本次范围内未观察到”，同时保留停止条件和持续监控。
把方法迁移到客服回复辅助
客服团队试点一套回复建议系统时，可以把“坐席打开了插件”当作入口，却不能当作采用。有效任务要连接工单开始、建议审阅、人工修改、客户回复和工单结果。
稳定采用者可能喜欢来源引用；放弃者可能在一次错误政策后失去信任；绕开者可能处理的是系统未覆盖的投诉类型。不同用户行为对应知识、交互、场景或组织问题，不能统一归为培训不足。
净价值也要包括主管抽检、知识维护、升级处理和风险事件。即使平均回复时间下降，高风险承诺增加或坐席需要逐字重写，项目也不应扩大。
试点结论可以是缩小到政策稳定的查询类工单，继续影子运行复杂投诉，或直接终止。能够根据证据停止项目，本身就是有效交付的一部分。
你的练习
从第 8 章确认可以进入小范围试点的项目开始。先写本次试点要支持的下一项决定，再定义用户、真实任务、环境、动作、人审、支持、时间窗口和停止条件。若缺少真实授权，使用影子或高保真模式并标明限制。
给任务定义可追踪的开始和结束，排除测试调用。画出从符合范围、启动、获得结果、采纳或拒绝到重复使用的漏斗，并保留每层分母。
同时记录端到端时间、实质修改、转人工、支持、维护、风险和运行成本。访谈至少覆盖稳定采用、尝试后放弃和绕开流程的人；若某类人不存在，也要说明招募和观察范围。
最后写一份决定报告。扩大、迭代、缩小、继续影子、暂停或终止都可以，决定必须引用证据、限制、负责人和下一复审日期。你可以使用练习册中的试点计划和试点结果与后续决定。
怎样判断答案是否合格
先检查分母。报告里的任务数能否回到真实任务清单？未开始、放弃、拒绝和转人工是否被保留？只展示成功运行时，采用结论不成立。
再核对时间和成本。生成耗时之外，准备、审阅、支持、维护和异常处理有没有记录？一次性建设成本和可能的长期运行成本是否分开？
请一名未参与试点的人分别复述“观察到什么”和“尚未证明什么”。若对方把短期提速理解成收入增长，报告的因果边界还不够清楚。
合格作业会改变项目范围、流程或决定。若试点结束后仍按原计划推广，只是补了一页“效果良好”，这段运行没有发挥学习作用。
本章小结：有人使用之后，才看得见范围问题
澄川的四名销售都登录过，只有两名在后半程形成了相对独立的重复使用。24 个符合范围的任务里，14 个完成提交；放弃与绕开暴露了客户关联、资料覆盖和恢复体验的问题。
局部提速信号没有覆盖支持与修复成本，也不能证明收入变化。团队因此决定缩小范围并继续改进。下一章将检查这条缩小后的流程和已经形成的评估、工具与运行资料，能否由第二团队复用，哪些部分值得长期维护，哪些应停止扩张。
本章来源与框架边界
- GOV.UK Service Manual：How the beta phase works（访问于 2026-08-04）
- GOV.UK Service Manual：Measuring completion rate（访问于 2026-08-04）
- GOV.UK Service Manual：Measuring the success of your service（访问于 2026-08-04）
采用漏斗、净价值表达、试点后的决定选项和澄川试点数据是本书的教学设计，不代表 GOV.UK 发布的企业 AI 试点标准。真实试点的样本、周期、效果判断和合规要求必须根据任务频率、风险、统计目的与所在组织重新设计。