「试点成功就能直接推广」这句话，错在把一次成立当成了普遍成立。用 AI 改造流程的团队，试点阶段通常有较好的数据、较配合的人、较密集的支持，这些条件在推广时基本消失。推广更像重新设计一遍，而不是把成功的做法复制粘贴。
误区一：把种子用户的手感当成普遍水平
错在样本选择。试点往往挑的是熟悉业务、愿意尝试的骨干，他们知道什么情况下该绕开工具，也知道输出不对时怎么补。换一批没参与过设计的人，同样的界面会被用出完全不同的结果。
正确说法是把人的因素写进验收。试点报告里要说明参与人的熟练度、培训时长、每天使用频次，并预估普通用户在这些指标上的差距。差距越大，推广时需要的培训和陪跑就越多。
误区二：忽略规模带来的成本与协调
错在按单点成本线性外推。十个人用和三百个人用，差别不只是调用量：账号要批量开通，权限要分层，出问题要有人接，跨部门的交接规则要重新谈。这些工作在小范围里靠口头就能解决，在大范围里必须成文。
正确说法是把推广成本拆成四块：账号与权限、培训与答疑、支持人手、流程改写。四块里最容易被低估的是支持人手，推广首月的咨询量通常是试点的五到十倍。
误区三：把一次成功当成稳定能力
错在没有观察波动。试点跑了一个月，数据好看，但这一个月可能正好是业务淡季，或者恰好没有遇到难例。缺少跨周期的观察，得到的是一条偏高的基线。
正确说法是至少覆盖一个完整周期，并单独统计难例上的表现。若难例占比不到一成，说明样本还没碰到真实的边角，此时的成功率不能作为推广依据。数据准备的问题可参考数据量与行业模型的讨论。
正确说法：推广是一次重新设计
推广要重新回答三个问题：新人怎么学会用、异常怎么找到人、出问题怎么退回。三个问题在试点阶段都被高强度的支持掩盖了，推广时必须把它们做成流程，而不是靠某个人在现场盯着。
所以推广的第一步应当是把支持结构搭起来，而不是先开通账号：每个片区一个联系人，一份常见问题清单，一条能当天响应的通道。这三样东西齐了，再谈上线节奏。
分批推广的节奏怎么定
建议按三批走：第一批选条件中等的一到两个点，跑两周看问题密度；第二批扩到三成，重点看支持是否跟得上；第三批全量，此时方案应已冻结，只允许修缺陷，不再加功能。
| 批次 | 范围 | 这一批主要看什么 |
|---|---|---|
| 第一批 | 条件中等的一到两个点 | 问题密度，跑两周看集中出现什么 |
| 第二批 | 扩到三成 | 支持是否跟得上 |
| 第三批 | 全量 | 方案已冻结，只允许修缺陷 |
每批之间留一周复盘，把新出现的问题归成三类：方案缺陷、培训不足、流程不适配。三类分别由不同的人处理，混在一起讨论会拖慢节奏。判断是否该继续，可参考最终判断由谁做的分工。每批都要留一份问题台账，记录类型、频次、处理人，三批下来就是下一轮迭代的需求清单。
推广期的另一个隐性成本是口径分裂。各点为了省事自行改字段，三个月后总部拿不到可比数据，原本想看的整体效果就算不出来。上线前把字段冻结，改动走统一入口；工具侧怎么收拢，可参考工具与数字化的距离。
推广前五问
- 试点参与人的熟练度，普通用户能达到几成
- 难例占比是否超过一成
- 支持人手是否按五倍咨询量准备
- 异常时能否当天找到人
- 方案是否已冻结，只修缺陷不加功能
各点的操作差异可以用 WPS AI 整理成对照表，再用扣子做成一个能查的小入口，复盘时一页看完，比逐点打电话问更省时间，也更容易发现口径已经分裂。
换个问法再问试点成功就能推广三句
- 试点效果很好，能不能跳过第二批直接全量？：不建议，支持能力没有经过压力测试，首月问题会集中爆发。
- 推广期效率下降多少算正常？：一到两成常见，超过三成说明培训或流程设计有问题。
- 要不要保留试点点作为样板？：要，但要撤掉特殊支持，让它和普通点跑一样的条件。
