学完这一课，你可以
- 按任务统计实际使用情况，找出工作停在哪一步。
- 分清合理拒绝与使用障碍，选择一项有依据的改进。
- 为试点安排能找到人、能暂停、能获得反馈的支持。
开始之前
- 带上第 8 课允许试用的任务、排除项、成功标准和停止条件；如果还没有，就先用纸面练习，不开放真实任务。
- 阅读北辰案例页和本课的两周任务情景。二十条入门事件与本课 340 次任务是不同材料，不能合并成一个效果样本。
先问工作有没有变，再看大家是否登录
上一课回答了“哪些任务可以试用”。这一课接着问：在这些任务出现时，用户能否借助系统把工作做完？这里的“使用情况”，也常称为采用（adoption），关注的是新的工作方式是否真正发生，而不是账户是否激活。
北辰的助手初期只能提供检查建议和准备备件申请草稿，不会自动停机、提交申请或发布事故结论。因此，“看到建议”和“处理完故障”是两件不同的事。你需要跟到人工决定、业务记录和结果核实，才知道哪一步得到了帮助。
登录多但工作没变，可能是入口不方便、来源版本不清、审批仍在等待，或主管要求每天打开。先找具体任务，不要把“不愿用”当作对人的判断。GOV.UK 的完成率指南提醒你为一次服务明确起点和终点；本课把这个思路用于企业任务，并另外保留未进入系统的合格任务。
用同一批任务算出漏斗
北辰本课的练习情景给出两周内 340 次符合试用范围的任务：打开系统 96 次，产生建议 88 次，采纳建议 41 次，按新方式完成 33 次，核实结果有效 31 次。这些是为教学编写的情景数字，不是二十条 JSON 事件的统计，也不是实际客户效果。
第一步先写统计规则：一次任务用什么编号识别，重复打开是否合并，跨周完成归到哪批，怎样确认最终结果。第二步把每一层都除以 340，得到范围内覆盖；再除以上一层，了解在哪一步流失。第三步从流失处抽取任务核对，不能仅凭差额猜原因。
下面的全程比例经过四舍五入。最终有效结果为 31/340，约 9.1%；打开后的有效结果为 31/96，约 32.3%。两个比例都可以用，但必须写清分母。看板另有 120 个账号、116 个月活，其账户范围未说明，不能推算 48 名工程师或 6 名专家的覆盖率，也不能替代任务统计。
| 任务走到哪一步 | 次数 | 占 340 次合格任务 |
|---|---|---|
| 符合试用范围 | 340 | 100% |
| 打开系统 | 96 | 28.2% |
| 产生建议 | 88 | 25.9% |
| 建议被采纳 | 41 | 12.1% |
| 按新方式完成 | 33 | 9.7% |
| 结果核实有效 | 31 | 9.1% |
从一次没有使用的经历找原因
先挑一条符合范围却没打开的任务，请使用者从接单开始讲：手边有什么，先做了什么，为什么选旧工具，最后怎样完成。接着对照一条打开后放弃的任务和一条成功完成的任务。相同的人在不同任务中做出不同选择，比“资深人员都抵触”更能帮助你找原因。
日志可以证明访问被拒绝、响应超时或按钮被点击，却通常不能证明当事人为什么选择旧流程。访谈能解释担忧，但也可能有记忆偏差。把两者与业务记录对照，保留相互不一致的地方。自学时可以写出三个竞争解释和要找的记录，不必假装已经访谈过客户。
不要预设培训一定有效。用户知道怎么点，却打不开手册，应该检查权限；专家没空复核，应该调整容量或缩小范围。下面是选择下一行动的参考，不是把所有人硬分成固定类型。同一任务也可能同时受到两种障碍影响。
| 你看到的情况 | 先检查什么 | 可能适合的改变 |
|---|---|---|
| 不知道哪些任务适用 | 入口说明能否对应手头任务 | 在任务入口说明适用范围 |
| 知道怎么用但打不开资料 | 当前身份与阅读权限 | 修正权限或排除不可访问的任务 |
| 建议有用但没人审核 | 当班复核量、积压和备份 | 补足支持或缩小试点 |
| 担心拒绝会影响考核 | 主管实际说法与考核规则 | 业务负责人明确合理拒绝规则 |
| 来源不清，用户退回旧工具 | 版本、撤回状态与具体错误 | 修正来源展示和知识管理 |
让修改和合理拒绝都有去处
采用并不要求每条建议都接受。工程师发现手册不适用于当前设备，拒绝建议并升级，是正确使用边界。你要分别记录接受、修改、按规则拒绝、找不到下一步而绕行，以及人工接手。没有任务层面的理由，单纯提高采纳率可能把安全判断也一起消除。
让用户能看见来源、说明修改理由、返回旧流程，并找到真正能处理问题的人。Microsoft 的人机交互指南强调易于拒绝和纠正，以及在不确定时收窄功能；这里把这些原则落实到检查建议和申请草稿。点击“拒绝”后如果工作停住，这个控制还不完整。
如果修改和拒绝突然变成零，先抽查建议是否真的适用，再了解主管是否要求不许改。不要据此断言用户已经盲信，也不要直接宣布系统完美。你需要把一个可疑信号转成具体检查。对反馈的绩效用途应事先获得明确约定，不偷偷把练习反馈变成员工排名。
把支持安排放进工作现场
试点开始前，用户应知道哪些任务能用、遇到状态未知时怎么停、谁回复、什么时候回复、没人接手时回到哪里。把这些说明放在工作入口和异常页面，比要求大家记住一份长手册更容易执行。首响应时限由运行负责人根据实际值班确认，不能照抄案例里某个数字。
估算支持量时，分开常规答疑、资料问题、权限事故和紧急暂停，按时段看人手。为了演示：如果每天 30 次求助平均各需 8 分钟处理，就需要 240 分钟处理时间；这还没有计入同时到来的请求、调查和休息。它不是四小时排班就一定够的证明。
GOV.UK 的支持指南将求助量、处理时间和反馈纳入服务改进。本课据此提醒你检查容量，而不是承诺一个统一服务水平。试点中每项反馈都应有人接收、判断、处理和回告；暂时不改也说明原因。正式工单变少时，核对用户是否改去私人群里求助。
选择一个改变，提前写下怎样判断
资源只够做一项改进时，优先选择与具体障碍相符、能在当前范围验证、又不会增加未评估风险的办法。写成一句话：针对谁的哪项困难，改变什么，观察哪些任务，在什么时间检查，什么结果说明原解释可能错了。期限和目标必须是你的练习假设或实际负责人确认的条件，不能冒充材料已有结论。
例如，你怀疑资深工程师担心拒绝建议会受罚。先查一次拒绝后的主管处理，若有依据，再建议由业务负责人说明拒绝和升级规则。观察下一段时间内合理拒绝是否有记录、适用任务是否完成、返工是否增加。如果规则澄清后仍打不开手册，就回到权限问题，不再追加同一种培训。
保留改变前后的版本、任务范围和其他同期变化。少量试点可以逐条看任务，不必硬凑统计显著性。一次可解释的改进能帮助你选择下一步；它还不能证明长期价值，更不能自动批准夜班或新区域使用。
避免把漂亮数字当成已经成功
常见误区是把全部账号、生成次数和培训签到拼成“采用成功”。这些信息可以检查可达性或安排支持，但没有说明合格任务怎样完成。另一个误区是只采访愿意配合的人；退出者和下游审核人往往能说明看板之外的成本。
也不要用“所有障碍都是培训无效”取代原来的简化判断。有些人确实需要情境练习；有些任务根本不应使用系统。你的结论应写成“这三条任务记录支持权限障碍，仍需确认其他班次”，而不是“用户不懂 AI”或“培训永远没用”。
动手练习
用本课北辰两周情景练习，不需要真实客户、生产系统或额外个人数据。你会写出一份任务统计、一项待验证改进和支持安排。
- 01
写出沿用第 8 课的允许与排除范围，并说明二十条 JSON 不包含本课漏斗数据。
- 02
计算各层占 340 的比例和最终 31/96 的比例，分别注明意义；列出还缺少的重复任务、修改与拒绝记录。
- 03
针对没有打开、打开后未产生建议、采纳后未完成，各写两个可能原因和一项能区分原因的检查。
- 04
选择一种障碍，拟定一项改进；把期限、目标和支持人数标为演示假设，说明结果不符时怎样修改判断。
- 05
写给试点用户的短说明：能做什么、不能做什么、合理拒绝怎么记录、谁支持、怎样暂停。自学时留下需要负责人确认的空项；有同伴时请其指出看不懂的步骤。
比较采用变化与新增负担
先复算 340 次任务的漏斗，再分别比较三种模拟改进的前后、对照、有效完成、错误与成本。
基线聚合与公开事件相合；逐行分配、干预结果和成本是新增模拟，不是实际试点或因果证明。
先读字段说明，完成计算或走查，再核对指南中的自检要点。文件可下载后用表格软件或文本编辑器阅读，无需运行代码。
检查你的理解
先写下自己的回答，再展开解析，看看还需要补充什么。
96 次打开、31 次有效结果，能否报告 32.3% 的任务覆盖？
不能。32.3% 的分母是打开的 96 次任务；范围内有效结果覆盖为 31/340，约 9.1%。两个口径要分开。
工程师拒绝过期手册建议，采纳率下降，要补培训吗？
先核对任务和版本。如果拒绝符合规则，这是控制正常发挥作用。应修复来源和撤回机制，而不是要求接受。
自学时没有访谈对象，怎样完成障碍分析？
用给定情景提出竞争解释和要找的证据，明确还没有验证。不要写出虚构访谈结果或批准真实试点。
本课记录与下一步
一张从合格任务到实际完成的使用统计图、各角色的工作量变化，以及支持安排。
你能用观察或记录解释不使用的原因；没有把登录次数当成价值；运行负责人确认有人能提供所需支持。
带着这份任务统计和支持缺口进入第 10 课：当业务负责人要求更快扩大，或试点再次出错，你要解释事实、保护用户，并让分歧形成明确选择。